Issue 19342: Unnamed elements in a namespace (uml2-rtf) Source: oose Innovative Informatik eG (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de) Nature: Uncategorized Issue Severity: Summary: I’ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Resolution: Revised Text: Actions taken: April 8, 2014: received issue Discussion: End of Annotations:===== m: Tim Weilkiens To: "uml2-rtf@omg.org" Subject: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/A== Date: Tue, 8 Apr 2014 19:49:04 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.197.239.164] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de From: Tim Weilkiens To: Michael Chonoles CC: "uml2-rtf@omg.org" Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAPD78AAAVhRfA= Date: Wed, 9 Apr 2014 05:51:37 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [178.197.239.209] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org I.ve checked it in MagicDraw. The name of the include relationship is empty and not set by the tool for example with the names of the linked use cases. The include relationship was only an example for my issue. The same issue occurs for example with two unnamed use cases in the same package. From: Michael Chonoles [mailto:mjchonoles@yahoo.com] Sent: Wednesday, April 09, 2014 7:00 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace My thoughts, and I believe is how some tools do it, is that the «include»s are actually named, but name is suppressed on the diagrams. If you try to make two includes between the same two use cases, you.ll find that they are the same. But two includes from the same base use case to two different use cases can be named the same, but are still distinguishable. And two includes from different use cases to the same use case, even if they have the same name, are distinguishable. Typically the name is baseUseCaseName-IncludedUseCaseName or something like that. Of course, a tool is able to literally skip the name and give it an unique xmi id for its own purposes. Thinking about this a bit, this implementation approach doesn.t solve your issue, which seems legitimate. And if use case inheritance is involved, that the sub-use case will inherit an include with the context sensitive name. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, April 08, 2014 3:49 PM To: uml2-rtf@omg.org Subject: Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de From: "BERNARD, Yves" To: Tim Weilkiens , "uml2-rtf@omg.org" Date: Wed, 9 Apr 2014 07:52:32 +0200 Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAVBC8A Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397022970; bh=j9KWjg0pHk+fjGUah5TdrGkmETJueV1i0Uyxh0HvEs4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=BaWkkVA+ODxvhRa5RIrVRfArudSvyeHRjUmpyovwHpEUtC/s3JcKnQR3UmRXhzIvtuorfi8tAfuAIMZXqk0zFzgeJoDU3WlDgFPF6IYDWSqNy+N3GIOPvjSVK4GJTBW5Yt3UIgSfoCiyn3hsJerGgRC/zisGtkxfkpHviqGjJ84= X-Yahoo-Newman-Id: 449331.19719.bm@smtp206.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vo_P8jQVM1mnIcuO6rXTXBgKxKGykFJLIO.4Ve.j5blGI_C hcmZfVpQNUTuJnyX.HlaIIBWZouZgFUPcJQonmb_5npFVVWO_4MZkgnwkluy V3qz1gKkGi4nwmJv12ngdIlkJJgpdH9mcEvwun1FXs88J1xXgU32RiSCI6T6 56klZdjzdLkoXrqYJCDCDHDx16FFwlFfEnUP1ONYgTRqswfvDacn5bOxkM0Y nZ87ekfGEg_01wteVjaK6gFcBYcu.4TZd9FhPQkQDPQWNZ8qcvmfJIvcMCcJ _nlBlAmYI85NBcPBU8JE1j0OV0a9s5nu0w76T.KROn5uwDcaWZ.f4iK_Ut6B uQ8YQr5xLqqzhuFGH9hvTOXLFfxSzyAwh0kvALG.OoP_rSZr75JJXeKkhaf8 O8pOfryFyoFR41RHrBQIqh0SFz2vm0qXStgq9eLeOknDdjwoa8_0WlZ7d6TV jMaFnflgmhjoqHlLsVOlgqvB6_zeQCcbr_PrgzetVcj5sj5B3fZp5NP03Kuk WlOZ8MsaqVNZi0GfT8CDbza5lKFKRLX.z2UJliWhN_REPTP4xfFy6mnx8WB9 2NU3zN9Cj X-Yahoo-SMTP: BHehp.2swBCs4PqecFo6LCqjUcnFjw4- X-Rocket-Received: from mjchonolesHP (mjchonoles@71.225.93.40 with plain [63.250.193.228]) by smtp206.mail.ne1.yahoo.com with SMTP; 08 Apr 2014 22:56:10 -0700 PDT From: "Michael Chonoles" To: "'Tim Weilkiens'" Cc: Subject: RE: Unnamed elements in a namespace Date: Wed, 9 Apr 2014 01:55:53 -0400 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHhGDc8WYnqk+zF915iG8JfgkRtMALCLCGmAooADaeaut4y4A== X-Virus-Scanned: amavisd-new at omg.org Then they probably use some internal XMI id. Seems like a legitimate issue. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, April 09, 2014 1:52 AM To: Michael Chonoles Cc: uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace I.ve checked it in MagicDraw. The name of the include relationship is empty and not set by the tool for example with the names of the linked use cases. The include relationship was only an example for my issue. The same issue occurs for example with two unnamed use cases in the same package. cid:image001.jpg@01CF5396.9E42EE20 From: Michael Chonoles [mailto:mjchonoles@yahoo.com] Sent: Wednesday, April 09, 2014 7:00 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace My thoughts, and I believe is how some tools do it, is that the «include»s are actually named, but name is suppressed on the diagrams. If you try to make two includes between the same two use cases, you.ll find that they are the same. But two includes from the same base use case to two different use cases can be named the same, but are still distinguishable. And two includes from different use cases to the same use case, even if they have the same name, are distinguishable. Typically the name is baseUseCaseName-IncludedUseCaseName or something like that. Of course, a tool is able to literally skip the name and give it an unique xmi id for its own purposes. Thinking about this a bit, this implementation approach doesn.t solve your issue, which seems legitimate. And if use case inheritance is involved, that the sub-use case will inherit an include with the context sensitive name. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, April 08, 2014 3:49 PM To: uml2-rtf@omg.org Subject: Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de From: Tim Weilkiens To: "BERNARD, Yves" , "uml2-rtf@omg.org" Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAVBC8AAAAYixA= Date: Wed, 9 Apr 2014 05:58:13 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.197.239.209] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: Tim Weilkiens , Michael Chonoles CC: "uml2-rtf@omg.org" Date: Wed, 9 Apr 2014 07:58:45 +0200 Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAPD78AAAVhRfAAALdGMA== Accept-Language: fr-FR, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Tim, For unnamed use cases, to me this is a bug. From a pure UML perspective, I see absolutely no means to distinguish between 2 use cases that have the same name in the same namespace. Only the tool can do that thanks to the UID. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:52 À: Michael Chonoles Cc : uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace I.ve checked it in MagicDraw. The name of the include relationship is empty and not set by the tool for example with the names of the linked use cases. The include relationship was only an example for my issue. The same issue occurs for example with two unnamed use cases in the same package. From: Michael Chonoles [mailto:mjchonoles@yahoo.com] Sent: Wednesday, April 09, 2014 7:00 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace My thoughts, and I believe is how some tools do it, is that the «include»s are actually named, but name is suppressed on the diagrams. If you try to make two includes between the same two use cases, you.ll find that they are the same. But two includes from the same base use case to two different use cases can be named the same, but are still distinguishable. And two includes from different use cases to the same use case, even if they have the same name, are distinguishable. Typically the name is baseUseCaseName-IncludedUseCaseName or something like that. Of course, a tool is able to literally skip the name and give it an unique xmi id for its own purposes. Thinking about this a bit, this implementation approach doesn.t solve your issue, which seems legitimate. And if use case inheritance is involved, that the sub-use case will inherit an include with the context sensitive name. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, April 08, 2014 3:49 PM To: uml2-rtf@omg.org Subject: Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Tim Weilkiens To: Michael Chonoles CC: "uml2-rtf@omg.org" Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAPD78AAAVhRfD//+R9gP//3cPw Date: Wed, 9 Apr 2014 05:59:42 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [178.197.239.209] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org I.ve just recognized that the UseCase has a constraint that it must have a name. I thought that MagicDraw won.t allow me to violate UML constraints. That.s an issue for NoMagic ;-) Tim From: Michael Chonoles [mailto:mjchonoles@yahoo.com] Sent: Wednesday, April 09, 2014 7:56 AM To: Tim Weilkiens Cc: uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Then they probably use some internal XMI id. Seems like a legitimate issue. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, April 09, 2014 1:52 AM To: Michael Chonoles Cc: uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace I.ve checked it in MagicDraw. The name of the include relationship is empty and not set by the tool for example with the names of the linked use cases. The include relationship was only an example for my issue. The same issue occurs for example with two unnamed use cases in the same package. cid:image001.jpg@01CF5396.9E42EE20 From: Michael Chonoles [mailto:mjchonoles@yahoo.com] Sent: Wednesday, April 09, 2014 7:00 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace My thoughts, and I believe is how some tools do it, is that the «include»s are actually named, but name is suppressed on the diagrams. If you try to make two includes between the same two use cases, you.ll find that they are the same. But two includes from the same base use case to two different use cases can be named the same, but are still distinguishable. And two includes from different use cases to the same use case, even if they have the same name, are distinguishable. Typically the name is baseUseCaseName-IncludedUseCaseName or something like that. Of course, a tool is able to literally skip the name and give it an unique xmi id for its own purposes. Thinking about this a bit, this implementation approach doesn.t solve your issue, which seems legitimate. And if use case inheritance is involved, that the sub-use case will inherit an include with the context sensitive name. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, April 08, 2014 3:49 PM To: uml2-rtf@omg.org Subject: Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de From: Tim Weilkiens To: "BERNARD, Yves" , Michael Chonoles CC: "uml2-rtf@omg.org" , "issues@omg.org" Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAVBC8AAAAYixAAAD/bAAAASCXg Date: Wed, 9 Apr 2014 06:13:13 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.197.239.209] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: Tim Weilkiens , Michael Chonoles CC: "uml2-rtf@omg.org" , "issues@omg.org" Date: Wed, 9 Apr 2014 08:13:30 +0200 Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAVBC8AAAAYixAAAD/bAAAASCXgAAApqSA= Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Agree. De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 08:13 À: BERNARD, Yves; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-Trusted-NM: yes Subject: Re: Unnamed elements in a namespace From: Nerijus Jankevicius Date: Wed, 9 Apr 2014 09:16:59 +0300 Cc: Michael Chonoles , "uml2-rtf@omg.org" To: Tim Weilkiens X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: amavisd-new at omg.org Tim, Thats an old issue and a headache for tool vendors. Tool must allow these .intermediate., incomplete states of the model while you are in the process of creation. So, all unnamed elements are especially ignored and allowed in the same namespace with the intention that modeler assigns unique names later. Model should be allowed to be incomplete in a tool. There are validation rules to check model completeness. Imagine you have an operation defined for class, and want to create another, with more parameters. Right after you create a new operation and name it, it may be exactly the same as one already created, you simply do not enter parameters yet. But tool should allow these .intermediate., incorrect model states. The similar issue (not related to name, but to other mandatory properties) and tool vendor decisions are with CallBehaviorActions which have no behaviors in intermediate state (or behavior is deleted), or SendSignalAction without mandatory target pin (which most users never use, including all UML spec examples and BPMN notation). Nerijus On Apr 9, 2014, at 8:59 AM, Tim Weilkiens wrote: I.ve just recognized that the UseCase has a constraint that it must have a name. I thought that MagicDraw won.t allow me to violate UML constraints. That.s an issue for NoMagic ;-) Tim From: Michael Chonoles [mailto:mjchonoles@yahoo.com] Sent: Wednesday, April 09, 2014 7:56 AM To: Tim Weilkiens Cc: uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Then they probably use some internal XMI id. Seems like a legitimate issue. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, April 09, 2014 1:52 AM To: Michael Chonoles Cc: uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace I.ve checked it in MagicDraw. The name of the include relationship is empty and not set by the tool for example with the names of the linked use cases. The include relationship was only an example for my issue. The same issue occurs for example with two unnamed use cases in the same package. From: Michael Chonoles [mailto:mjchonoles@yahoo.com] Sent: Wednesday, April 09, 2014 7:00 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace My thoughts, and I believe is how some tools do it, is that the «include»s are actually named, but name is suppressed on the diagrams. If you try to make two includes between the same two use cases, you.ll find that they are the same. But two includes from the same base use case to two different use cases can be named the same, but are still distinguishable. And two includes from different use cases to the same use case, even if they have the same name, are distinguishable. Typically the name is baseUseCaseName-IncludedUseCaseName or something like that. Of course, a tool is able to literally skip the name and give it an unique xmi id for its own purposes. Thinking about this a bit, this implementation approach doesn.t solve your issue, which seems legitimate. And if use case inheritance is involved, that the sub-use case will inherit an include with the context sensitive name. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, April 08, 2014 3:49 PM To: uml2-rtf@omg.org Subject: Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de From: "Wendland, Marc-Florian" To: Nerijus Jankevicius , Tim Weilkiens CC: Michael Chonoles , "uml2-rtf@omg.org" Subject: AW: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TvFe3RaWFsijtRoiKA6SPHw1Z/A== Date: Wed, 9 Apr 2014 06:24:20 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-kse-antivirus-interceptor-info: protection disabled X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml2-rtf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate39-dus with 7F5C72018011 X-cloud-security-connect: smtpsrv2.fokus.fraunhofer.de[195.37.77.176], TLS=, IP=195.37.77.176 X-cloud-security: scantime:.3946 X-Virus-Scanned: amavisd-new at omg.org Hi all, I agree with Nerius statement. Incompleteness should be allowed by tools, respectively it is in the tools vendor's responsibility to decide which constraints are supposed to be validate in live and batch mode. At a certain point in time when the model is deemed complete, it is up to the validation rules to verify or falsify the validity of the model. Papyrus, for example, adds a default name for newly created NamedElements. Regards, Marc-Florian -------- Ursprühe Nachricht -------- Von: Nerijus Jankevicius Datum:09.04.2014 08:17 (GMT+01:00) An: Tim Weilkiens Cc: Michael Chonoles ,uml2-rtf@omg.org Betreff: Re: Unnamed elements in a namespace Tim, Thats an old issue and a headache for tool vendors. Tool must allow these .intermediate., incomplete states of the model while you are in the process of creation. So, all unnamed elements are especially ignored and allowed in the same namespace with the intention that modeler assigns unique names later. Model should be allowed to be incomplete in a tool. There are validation rules to check model completeness. Imagine you have an operation defined for class, and want to create another, with more parameters. Right after you create a new operation and name it, it may be exactly the same as one already created, you simply do not enter parameters yet. But tool should allow these .intermediate., incorrect model states. The similar issue (not related to name, but to other mandatory properties) and tool vendor decisions are with CallBehaviorActions which have no behaviors in intermediate state (or behavior is deleted), or SendSignalAction without mandatory target pin (which most users never use, including all UML spec examples and BPMN notation). Nerijus On Apr 9, 2014, at 8:59 AM, Tim Weilkiens wrote: I.ve just recognized that the UseCase has a constraint that it must have a name. I thought that MagicDraw won.t allow me to violate UML constraints. That.s an issue for NoMagic ;-) Tim From: Michael Chonoles [mailto:mjchonoles@yahoo.com] Sent: Wednesday, April 09, 2014 7:56 AM To: Tim Weilkiens Cc: uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Then they probably use some internal XMI id. Seems like a legitimate issue. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, April 09, 2014 1:52 AM To: Michael Chonoles Cc: uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace I.ve checked it in MagicDraw. The name of the include relationship is empty and not set by the tool for example with the names of the linked use cases. The include relationship was only an example for my issue. The same issue occurs for example with two unnamed use cases in the same package. From: Michael Chonoles [mailto:mjchonoles@yahoo.com] Sent: Wednesday, April 09, 2014 7:00 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace My thoughts, and I believe is how some tools do it, is that the «include»s are actually named, but name is suppressed on the diagrams. If you try to make two includes between the same two use cases, you.ll find that they are the same. But two includes from the same base use case to two different use cases can be named the same, but are still distinguishable. And two includes from different use cases to the same use case, even if they have the same name, are distinguishable. Typically the name is baseUseCaseName-IncludedUseCaseName or something like that. Of course, a tool is able to literally skip the name and give it an unique xmi id for its own purposes. Thinking about this a bit, this implementation approach doesn.t solve your issue, which seems legitimate. And if use case inheritance is involved, that the sub-use case will inherit an include with the context sensitive name. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, April 08, 2014 3:49 PM To: uml2-rtf@omg.org Subject: Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de From: Tim Weilkiens To: Nerijus Jankevicius CC: Michael Chonoles , "uml2-rtf@omg.org" Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAPD78AAAVhRfD//+R9gP//3cPwgAAoIoD//9whMA== Date: Wed, 9 Apr 2014 06:28:03 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.197.239.209] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org Hi Nerijus, That.s obviously a cause for headache. I agree that tools must support intermediate states of an invalid model. Maybe my tool installation is not well configured, but the validation of my model with two unnamed use cases in the same package does not detect the violated constraint. Probably it is missing in your validation rule set. Tim From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 09, 2014 8:17 AM To: Tim Weilkiens Cc: Michael Chonoles; uml2-rtf@omg.org Subject: Re: Unnamed elements in a namespace Tim, Thats an old issue and a headache for tool vendors. Tool must allow these .intermediate., incomplete states of the model while you are in the process of creation. So, all unnamed elements are especially ignored and allowed in the same namespace with the intention that modeler assigns unique names later. Model should be allowed to be incomplete in a tool. There are validation rules to check model completeness. Imagine you have an operation defined for class, and want to create another, with more parameters. Right after you create a new operation and name it, it may be exactly the same as one already created, you simply do not enter parameters yet. But tool should allow these .intermediate., incorrect model states. The similar issue (not related to name, but to other mandatory properties) and tool vendor decisions are with CallBehaviorActions which have no behaviors in intermediate state (or behavior is deleted), or SendSignalAction without mandatory target pin (which most users never use, including all UML spec examples and BPMN notation). Nerijus On Apr 9, 2014, at 8:59 AM, Tim Weilkiens wrote: I.ve just recognized that the UseCase has a constraint that it must have a name. I thought that MagicDraw won.t allow me to violate UML constraints. That.s an issue for NoMagic ;-) Tim From: Michael Chonoles [mailto:mjchonoles@yahoo.com] Sent: Wednesday, April 09, 2014 7:56 AM To: Tim Weilkiens Cc: uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Then they probably use some internal XMI id. Seems like a legitimate issue. Michael From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, April 09, 2014 1:52 AM To: Michael Chonoles Cc: uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace I.ve checked it in MagicDraw. The name of the include relationship is empty and not set by the tool for example with the names of the linked use cases. The include relationship was only an example for my issue. The same issue occurs for example with two unnamed use cases in the same package. From: Michael Chonoles [mailto:mjchonoles@yahoo.com] Sent: Wednesday, April 09, 2014 7:00 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace My thoughts, and I believe is how some tools do it, is that the «include»s are actually named, but name is suppressed on the diagrams. If you try to make two includes between the same two use cases, you.ll find that they are the same. But two includes from the same base use case to two different use cases can be named the same, but are still distinguishable. And two includes from different use cases to the same use case, even if they have the same name, are distinguishable. Typically the name is baseUseCaseName-IncludedUseCaseName or something like that. Of course, a tool is able to literally skip the name and give it an unique xmi id for its own purposes. Thinking about this a bit, this implementation approach doesn.t solve your issue, which seems legitimate. And if use case inheritance is involved, that the sub-use case will inherit an include with the context sensitive name. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, April 08, 2014 3:49 PM To: uml2-rtf@omg.org Subject: Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de From: Axel Scheithauer To: Tim Weilkiens , "BERNARD, Yves" , Michael Chonoles CC: "uml2-rtf@omg.org" , "issues@omg.org" Subject: AW: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAVBC8AAAAYixAAAD/bAAAASCXgAAN0PTA= Date: Wed, 9 Apr 2014 09:08:18 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.85] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: Axel Scheithauer , Tim Weilkiens , Michael Chonoles CC: "uml2-rtf@omg.org" , "issues@omg.org" Date: Wed, 9 Apr 2014 12:35:02 +0200 Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAVBC8AAAAYixAAAD/bAAAASCXgAAN0PTAABP81MA== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Axel, I think you mix up distinguishability and identity which is not the same thing. Nobody said that 2 elements that are not distinguishable are the same; rather the specification says that they cannot co-exist in the same namespace. That is they are not distinguishable *for UML* only. In addition, as Nerijus pointed out, it is reasonable (and even required) that a modeling tool does not enforce all the constraints of the metamodel at all times but you should be able to check them .on demand., e.g. when you consider they should be. isDistinguishableFrom() is bugged anyway since, as specified in 2.5 it will return true for two unnamed elements of the same type. I don.t think that redefining it everywhere it is required is that painful. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 11:08 À: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Axel Scheithauer To: "BERNARD, Yves" , Tim Weilkiens , Michael Chonoles CC: "uml2-rtf@omg.org" , "issues@omg.org" Subject: AW: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAVBC8AAAAYixAAAD/bAAAASCXgAAN0PTAABP81MAACsGDg Date: Wed, 9 Apr 2014 12:18:29 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.85] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org Hi Yves, All Model elements are distinguishable for *UML*, no matter whether they have a name or not. In fact, to my knowledge, it is not even possible for any UML-Element to refer to the name of another element (except in an OpaqueExpression). Therefore the name isDistinguishableFrom() doesn.t make sense (or, as the discussion shows, is misleading). I agree that isDistinguishableFrom() is bugged, but the bug is it.s name. It may be difficult to investigate the original intent of this operation, but my claim is, that my suggested name is closer to it. I must admit, that this view is only supported by the current usage and implementation of it and a general feeling for the spirit of the definition. Additionally I think the implementation makes sense as it is. The reason for NamedElements (a better name would be NameableElement) not necessarily having a name is not primarily, that tools need to save incomplete models. It rather is, that the modeler often doesn.t want to bother with a name (do you name your Include-relationsships?). If the modeler wants to refer to it in an OpaqueExpression, then she needs to use a name, and can do so since it is a NamedElement. Specifying other distinguishing attributes would for example allow to safely refer to an Include-Relationsship based on sources and targets (and be sure, that there can only be one). Is there anybody out there, who wants to do this? As it is not necessary to distinguish Model-Elements by attributes, it also is not necessary to identify these attributes. It could be necessary, if we want to express any constraints on these attributes. But nobody suggested any new constraints yet. Axel Von: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Gesendet: Mittwoch, 9. April 2014 12:35 An: Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Axel, I think you mix up distinguishability and identity which is not the same thing. Nobody said that 2 elements that are not distinguishable are the same; rather the specification says that they cannot co-exist in the same namespace. That is they are not distinguishable *for UML* only. In addition, as Nerijus pointed out, it is reasonable (and even required) that a modeling tool does not enforce all the constraints of the metamodel at all times but you should be able to check them .on demand., e.g. when you consider they should be. isDistinguishableFrom() is bugged anyway since, as specified in 2.5 it will return true for two unnamed elements of the same type. I don.t think that redefining it everywhere it is required is that painful. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 11:08 À: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: Axel Scheithauer , Tim Weilkiens , Michael Chonoles CC: "uml2-rtf@omg.org" , "issues@omg.org" Date: Wed, 9 Apr 2014 14:59:18 +0200 Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAVBC8AAAAYixAAAD/bAAAASCXgAAN0PTAABP81MAACsGDgAAKR+XA= Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Axel, I think you still confuse between identity and distinguishability. Let.s try with a metaphor. Assume you are facing two .true. (and perfect) twin brothers. One is Peter and the other is John but you don.t know who is who because you have no clue about it. You can refer to one of them independently of the other because they actually have a distinct identity but you cannot know whether his is John or Peter even with a fully detailed description because they are not distinguishable. It does not make sense to speak about distinguishability when the identity is the same: if .two. items have the same identity they are obviously undistinguishable. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 14:18 À: BERNARD, Yves; Tim Weilkiens; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace Hi Yves, All Model elements are distinguishable for *UML*, no matter whether they have a name or not. In fact, to my knowledge, it is not even possible for any UML-Element to refer to the name of another element (except in an OpaqueExpression). Therefore the name isDistinguishableFrom() doesn.t make sense (or, as the discussion shows, is misleading). I agree that isDistinguishableFrom() is bugged, but the bug is it.s name. It may be difficult to investigate the original intent of this operation, but my claim is, that my suggested name is closer to it. I must admit, that this view is only supported by the current usage and implementation of it and a general feeling for the spirit of the definition. Additionally I think the implementation makes sense as it is. The reason for NamedElements (a better name would be NameableElement) not necessarily having a name is not primarily, that tools need to save incomplete models. It rather is, that the modeler often doesn.t want to bother with a name (do you name your Include-relationsships?). If the modeler wants to refer to it in an OpaqueExpression, then she needs to use a name, and can do so since it is a NamedElement. Specifying other distinguishing attributes would for example allow to safely refer to an Include-Relationsship based on sources and targets (and be sure, that there can only be one). Is there anybody out there, who wants to do this? As it is not necessary to distinguish Model-Elements by attributes, it also is not necessary to identify these attributes. It could be necessary, if we want to express any constraints on these attributes. But nobody suggested any new constraints yet. Axel Von: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Gesendet: Mittwoch, 9. April 2014 12:35 An: Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Axel, I think you mix up distinguishability and identity which is not the same thing. Nobody said that 2 elements that are not distinguishable are the same; rather the specification says that they cannot co-exist in the same namespace. That is they are not distinguishable *for UML* only. In addition, as Nerijus pointed out, it is reasonable (and even required) that a modeling tool does not enforce all the constraints of the metamodel at all times but you should be able to check them .on demand., e.g. when you consider they should be. isDistinguishableFrom() is bugged anyway since, as specified in 2.5 it will return true for two unnamed elements of the same type. I don.t think that redefining it everywhere it is required is that painful. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 11:08 À: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397055188; bh=wgsqNd9gIkVvH6Dy/nkN4zTtTMdgYCXwWTtk6bx4RYY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=3lN5mbylHrO2BNt4wyaT2VNX5K9OlbNFeYRxgqHFeCSjm37VSXl2Li1oR+sBKMb1oJuZMelodPV4A2NA3H1FC4XyBPNihPzCA/yaWxmoQFWOXbxtlfkZx4uTnukvMy1F9bffh0YvFw3SkPVvNHbtAooWl8/M4KPe62BMYnTecEU= X-Yahoo-Newman-Id: 57241.47089.bm@smtp217.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: hfyHt4MVM1lN6XFv6leAiAT_3vCowujWegiliOX_xNd6l6Y SV4iKB8dWcbQfH0cSFXYZWr.yATztlVmB5RcPee3dFIUfWDeRmf82kmwfpgT PQelnb7Usoeao8fugA2eKnTI.i0uGBIqyEgkNiHB2nTFGfiRqNbj.l0_Qfu5 f57wDNzgzdWXM1X8QC65lHmOvYpCSMtk3yOpysLRBSYX8SsC3_2dnXzHciQZ PalGZsRd1YZqR2kfRMVnA.PFROVGrD5jK5Th2iVYreaotbD3_dN6GkZtrLz8 NJI_qo5nrAdAbri6kI2ePOKuLTCrSI_e9HLVSV_x7gQCaMztpv5uyWzXiLhK WxL8zYFYOUKkPmEGj_G3aYosr3Mnbr6ItZgN3oHik9.TlYZUsT0qFqWM_vL8 pGiog8KzR5POpNDP0hytfWRaRLmjcJuIh4DvXocROBAfwB9pB9dREKLxOcCx VKO5K4SJBXXhaKfP4Rs4Q4bRPN3JvWu8cWqQJvF2Ed9CrpSjms6hdEQ2ihZu OKktUkm8_vAmWI6.qZ_gbKSluF.7WUyxsii21TLMOa.s5Bpc3O8HavnunrwG 9ITFVTXZ59koI X-Yahoo-SMTP: BHehp.2swBCs4PqecFo6LCqjUcnFjw4- X-Rocket-Received: from mjchonolesHP (mjchonoles@71.225.93.40 with plain [63.250.193.228]) by smtp217.mail.ne1.yahoo.com with SMTP; 09 Apr 2014 14:53:07 +0000 UTC From: "Michael Chonoles" To: "'Axel Scheithauer'" , "'Tim Weilkiens'" , "'BERNARD, Yves'" Cc: , Subject: RE: Unnamed elements in a namespace Date: Wed, 9 Apr 2014 10:52:49 -0400 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKrU2+rDGY0Mwlm+XUqsd2q6ICa+gFtfC6AAkXTCtcBEsbQAgH0AGWrANTzDKGZFOcBMA== X-Virus-Scanned: amavisd-new at omg.org However, if you have 2 associations between the same ends, which is legal, and often desirable, then they both can.t be unnamed, and then they both can.t have the same name Michael From: Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Sent: Wednesday, April 09, 2014 5:08 AM To: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Subject: AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397055188; bh=wgsqNd9gIkVvH6Dy/nkN4zTtTMdgYCXwWTtk6bx4RYY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=3lN5mbylHrO2BNt4wyaT2VNX5K9OlbNFeYRxgqHFeCSjm37VSXl2Li1oR+sBKMb1oJuZMelodPV4A2NA3H1FC4XyBPNihPzCA/yaWxmoQFWOXbxtlfkZx4uTnukvMy1F9bffh0YvFw3SkPVvNHbtAooWl8/M4KPe62BMYnTecEU= X-Yahoo-Newman-Id: 57241.47089.bm@smtp217.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: hfyHt4MVM1lN6XFv6leAiAT_3vCowujWegiliOX_xNd6l6Y SV4iKB8dWcbQfH0cSFXYZWr.yATztlVmB5RcPee3dFIUfWDeRmf82kmwfpgT PQelnb7Usoeao8fugA2eKnTI.i0uGBIqyEgkNiHB2nTFGfiRqNbj.l0_Qfu5 f57wDNzgzdWXM1X8QC65lHmOvYpCSMtk3yOpysLRBSYX8SsC3_2dnXzHciQZ PalGZsRd1YZqR2kfRMVnA.PFROVGrD5jK5Th2iVYreaotbD3_dN6GkZtrLz8 NJI_qo5nrAdAbri6kI2ePOKuLTCrSI_e9HLVSV_x7gQCaMztpv5uyWzXiLhK WxL8zYFYOUKkPmEGj_G3aYosr3Mnbr6ItZgN3oHik9.TlYZUsT0qFqWM_vL8 pGiog8KzR5POpNDP0hytfWRaRLmjcJuIh4DvXocROBAfwB9pB9dREKLxOcCx VKO5K4SJBXXhaKfP4Rs4Q4bRPN3JvWu8cWqQJvF2Ed9CrpSjms6hdEQ2ihZu OKktUkm8_vAmWI6.qZ_gbKSluF.7WUyxsii21TLMOa.s5Bpc3O8HavnunrwG 9ITFVTXZ59koI X-Yahoo-SMTP: BHehp.2swBCs4PqecFo6LCqjUcnFjw4- X-Rocket-Received: from mjchonolesHP (mjchonoles@71.225.93.40 with plain [63.250.193.228]) by smtp217.mail.ne1.yahoo.com with SMTP; 09 Apr 2014 14:53:07 +0000 UTC From: "Michael Chonoles" To: "'Axel Scheithauer'" , "'Tim Weilkiens'" , "'BERNARD, Yves'" Cc: , Subject: RE: Unnamed elements in a namespace Date: Wed, 9 Apr 2014 10:52:49 -0400 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKrU2+rDGY0Mwlm+XUqsd2q6ICa+gFtfC6AAkXTCtcBEsbQAgH0AGWrANTzDKGZFOcBMA== X-Virus-Scanned: amavisd-new at omg.org However, if you have 2 associations between the same ends, which is legal, and often desirable, then they both can.t be unnamed, and then they both can.t have the same name Michael From: Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Sent: Wednesday, April 09, 2014 5:08 AM To: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Subject: AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: Michael Chonoles , "'Axel Scheithauer'" , "'Tim Weilkiens'" CC: "uml2-rtf@omg.org" , "issues@omg.org" Date: Wed, 9 Apr 2014 17:06:08 +0200 Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: AQKrU2+rDGY0Mwlm+XUqsd2q6ICa+gFtfC6AAkXTCtcBEsbQAgH0AGWrANTzDKGZFOcBMIAAAeSQ Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Yes, or rather I would say that the model is not valid if they have the same name because one of the uml::Namespace.s constraint is violated. By the way, it is not violated when both are not named but this results from a bug in the OCL specified for NamedElement::isDistinguishableFrom(). Yves De : Michael Chonoles [mailto:mjchonoles@yahoo.com] Envoyé mercredi 9 avril 2014 16:53 À: 'Axel Scheithauer'; 'Tim Weilkiens'; BERNARD, Yves Cc : uml2-rtf@omg.org; issues@omg.org Objet : RE: Unnamed elements in a namespace However, if you have 2 associations between the same ends, which is legal, and often desirable, then they both can.t be unnamed, and then they both can.t have the same name Michael From: Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Sent: Wednesday, April 09, 2014 5:08 AM To: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Subject: AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-Virus-Scanned: OK From: Ed Seidewitz To: Axel Scheithauer , "BERNARD, Yves" , Tim Weilkiens , "Michael Chonoles" CC: "uml2-rtf@omg.org" , "issues@omg.org" Subject: Re: AW: Unnamed elements in a namespace Thread-Topic: AW: Unnamed elements in a namespace Thread-Index: AQHPVAeyBCsjLoz5EEyvro8IQfiWdQ== Date: Wed, 9 Apr 2014 15:23:44 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [108.51.109.141] X-Virus-Scanned: amavisd-new at omg.org This is not a new issue. And Axel.s position is pretty much the right one. One has to remember that, with a very few exceptions (package merge and an unfortunate case in interactions), naming has no real semantic impact in UML at all. The intent of namespaces were simply to be able to model the naming constructs found in programming languages and to provide a way to identify UML elements by name for external purposes (like from the bodies of OpaqueExpressions, as Axel mentions). .Distinguishibility., such as it is, only makes sense for UML in this context. The only reason that there is a constraint that members of a Namespace be .distinguishable. is so that one can identify the members uniquely by name . but this is only important if naming is important, which, as I mentioned above, is not really intrinsic to UML. If you decide not to name some element in your model, I don.t think UML should have a rule forcing you to do so, or disallow having multiple such unnamed elements in any one namespace . it simply means that you have no need to identify that element by name for the purpose of your model. Indeed, because of the way the UML metamodel is structured (e.g., all PackageableElements are NamedElements), there are unfortunately a lot of cases of elements that are NamedElements but for which one rarely wants to provide a name (such as Include) or often don.t want to (such as Associations). That is why isDistinguishableFrom intentially excludes unnamed elements and allows any number of unnamed members within a namespace. As Axel said, this operation could, perhaps, be better named, but it.s function is as intended. So, the real constraint on Namespaces is that all members with names are distinguishable . there is no general constraint on members without names. And this is a feature not a bug! If you want to be able to identify all members of some namespace by name, then you should impose your own modeling constraint to give all the members names. But UML should not force you to do that generally. And, otherwise, there is really no further need for .distinguishability.. As Axel has mentioned, all elements of a UML model are already distinct simply by being different elements . there is no general requirement to have them .distinguishable. in any other way. And, indeed, such a requirement would often just be a nuisance (if you want to disallow two Includes relationships between the same two UseCases, then that should be justified on semantic grounds, not because they need to be in some way .distinguishable.). . Ed From: Axel Scheithauer Date: Wednesday, April 9, 2014 at 8:18 AM To: Yves BERNARD , Tim Weilkiens , Michael Chonoles Cc: "uml2-rtf@omg.org" , "issues@omg.org" Subject: AW: Unnamed elements in a namespace Hi Yves, All Model elements are distinguishable for *UML*, no matter whether they have a name or not. In fact, to my knowledge, it is not even possible for any UML-Element to refer to the name of another element (except in an OpaqueExpression). Therefore the name isDistinguishableFrom() doesn.t make sense (or, as the discussion shows, is misleading). I agree that isDistinguishableFrom() is bugged, but the bug is it.s name. It may be difficult to investigate the original intent of this operation, but my claim is, that my suggested name is closer to it. I must admit, that this view is only supported by the current usage and implementation of it and a general feeling for the spirit of the definition. Additionally I think the implementation makes sense as it is. The reason for NamedElements (a better name would be NameableElement) not necessarily having a name is not primarily, that tools need to save incomplete models. It rather is, that the modeler often doesn.t want to bother with a name (do you name your Include-relationsships?). If the modeler wants to refer to it in an OpaqueExpression, then she needs to use a name, and can do so since it is a NamedElement. Specifying other distinguishing attributes would for example allow to safely refer to an Include-Relationsship based on sources and targets (and be sure, that there can only be one). Is there anybody out there, who wants to do this? As it is not necessary to distinguish Model-Elements by attributes, it also is not necessary to identify these attributes. It could be necessary, if we want to express any constraints on these attributes. But nobody suggested any new constraints yet. Axel Von: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Gesendet: Mittwoch, 9. April 2014 12:35 An: Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Axel, I think you mix up distinguishability and identity which is not the same thing. Nobody said that 2 elements that are not distinguishable are the same; rather the specification says that they cannot co-exist in the same namespace. That is they are not distinguishable *for UML* only. In addition, as Nerijus pointed out, it is reasonable (and even required) that a modeling tool does not enforce all the constraints of the metamodel at all times but you should be able to check them .on demand., e.g. when you consider they should be. isDistinguishableFrom() is bugged anyway since, as specified in 2.5 it will return true for two unnamed elements of the same type. I don.t think that redefining it everywhere it is required is that painful. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 11:08 À: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=Is6QcdPg c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=pYSs4GWjAFcA:10 a=1cg86FBCSn4A:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=CjxXgO3LAAAA:8 a=KHpXyVWLAAAA:8 a=97WRd6UGAAAA:8 a=I3cdlrxjAAAA:8 a=oCcaPWc0AAAA:8 a=SRfEvbYnluQbTbWHYfMA:9 a=RJfuywerSEsPF2_J:21 a=59pi6lxomPH1YsWB:21 a=7bmNQ2ZECAL8KhjO:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=rC2wZJ5BpNYA:10 a=WP4_USCxRkkA:10 a=DLrAvYGtb7wA:10 a=VWtqRZUfChcA:10 Date: Wed, 09 Apr 2014 16:26:27 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 To: "BERNARD, Yves" , Michael Chonoles , "'Axel Scheithauer'" , "'Tim Weilkiens'" CC: "uml2-rtf@omg.org" , "issues@omg.org" Subject: Re: Unnamed elements in a namespace X-Virus-Scanned: amavisd-new at omg.org Hi While discussing bugs in OCL we also have the related issues: It is customary to leave Operation pre/postconditions unnamed, so they are not distinguishable. Multiple Constraints may also be unnamed. Collection types are named without qualification, so Set(Boolean) and My::Set(Boolean) are not distinguishable types. Regards Ed Willink On 09/04/2014 16:06, BERNARD, Yves wrote: Yes, or rather I would say that the model is not valid if they have the same name because one of the uml::Namespace.s constraint is violated. By the way, it is not violated when both are not named but this results from a bug in the OCL specified for NamedElement::isDistinguishableFrom(). Yves De : Michael Chonoles [mailto:mjchonoles@yahoo.com] Envoyé mercredi 9 avril 2014 16:53 À: 'Axel Scheithauer'; 'Tim Weilkiens'; BERNARD, Yves Cc : uml2-rtf@omg.org; issues@omg.org Objet : RE: Unnamed elements in a namespace However, if you have 2 associations between the same ends, which is legal, and often desirable, then they both can.t be unnamed, and then they both can.t have the same name Michael From: Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Sent: Wednesday, April 09, 2014 5:08 AM To: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Subject: AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4355 / Virus Database: 3882/7318 - Release Date: 04/08/14 X-Virus-Scanned: OK From: Ed Seidewitz To: "BERNARD, Yves" , Michael Chonoles , "'Axel Scheithauer'" , "'Tim Weilkiens'" CC: "uml2-rtf@omg.org" , "issues@omg.org" Subject: Re: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AFtfC6AAkXTCtcBEsbQAgH0AGWrANTzDKGZFOcBMIAAAeSQ5q/46gA= Date: Wed, 9 Apr 2014 15:27:49 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [108.51.109.141] X-Virus-Scanned: amavisd-new at omg.org Yves . It is not a bug, it is a feature, and quite intentional. What Axel was suggesting was that two associations with different ends be allowed to have the same name. This makes sense. He was not suggesting that associations with the same ends have to be named. Most people do not name associations, and it would be very annoying to have to name two association just because they happen to be between the same classifiers. If a modeler wants to distinguish such associations by names, then the modeler can give them names. If there is no need to so distinguish them, then they can remain unnamed. There is no syntactic or semantic reason within UML to require otherwise. . Ed From: , Yves BERNARD Date: Wednesday, April 9, 2014 at 11:06 AM To: Michael Chonoles , Axel Scheithauer , Tim Weilkiens Cc: "uml2-rtf@omg.org" , "issues@omg.org" Subject: RE: Unnamed elements in a namespace Yes, or rather I would say that the model is not valid if they have the same name because one of the uml::Namespace.s constraint is violated. By the way, it is not violated when both are not named but this results from a bug in the OCL specified for NamedElement::isDistinguishableFrom(). Yves De : Michael Chonoles [mailto:mjchonoles@yahoo.com] Envoyé mercredi 9 avril 2014 16:53 À: 'Axel Scheithauer'; 'Tim Weilkiens'; BERNARD, Yves Cc : uml2-rtf@omg.org; issues@omg.org Objet : RE: Unnamed elements in a namespace However, if you have 2 associations between the same ends, which is legal, and often desirable, then they both can.t be unnamed, and then they both can.t have the same name Michael From: Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Sent: Wednesday, April 09, 2014 5:08 AM To: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Subject: AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-Virus-Scanned: OK From: Ed Seidewitz To: "BERNARD, Yves" , Axel Scheithauer , Tim Weilkiens , "Michael Chonoles" CC: "uml2-rtf@omg.org" , "issues@omg.org" Subject: Re: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAVBC8AAAAYixAAAD/bAAAASCXgAAN0PTAABP81MAACsGDgAAKR+XAACBrCgA== Date: Wed, 9 Apr 2014 15:33:23 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [108.51.109.141] X-Virus-Scanned: amavisd-new at omg.org Yves . I can always tell twin from the other, because, if I shoot one, the other does not die (or, less drastically, if I put a hat on one, the other still has a bare head!). This is just a reflection of the basic concept of object identity. And all UML elements have that when represented as instances of metaclasses. Now, if I really need to tell the twins apart on sight, I can place a name tag on one with the name .Peter. and a name tag on the other with the name .John.. For my own purposes, it doesn.t really matter which I name which (as long as they don.t switch their name tags behind my back). However, it is not useful to give them the same name, because this doesn.t help me tell them apart. So, if I want to tell the twins apart by name, then I need to give them distinguishable names. But if I don.t care to name them, then it is OK for them both to be unnamed. . Ed From: , Yves BERNARD Date: Wednesday, April 9, 2014 at 8:59 AM To: Axel Scheithauer , Tim Weilkiens , Michael Chonoles Cc: "uml2-rtf@omg.org" , "issues@omg.org" Subject: RE: Unnamed elements in a namespace Axel, I think you still confuse between identity and distinguishability. Let.s try with a metaphor. Assume you are facing two .true. (and perfect) twin brothers. One is Peter and the other is John but you don.t know who is who because you have no clue about it. You can refer to one of them independently of the other because they actually have a distinct identity but you cannot know whether his is John or Peter even with a fully detailed description because they are not distinguishable. It does not make sense to speak about distinguishability when the identity is the same: if .two. items have the same identity they are obviously undistinguishable. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 14:18 À: BERNARD, Yves; Tim Weilkiens; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace Hi Yves, All Model elements are distinguishable for *UML*, no matter whether they have a name or not. In fact, to my knowledge, it is not even possible for any UML-Element to refer to the name of another element (except in an OpaqueExpression). Therefore the name isDistinguishableFrom() doesn.t make sense (or, as the discussion shows, is misleading). I agree that isDistinguishableFrom() is bugged, but the bug is it.s name. It may be difficult to investigate the original intent of this operation, but my claim is, that my suggested name is closer to it. I must admit, that this view is only supported by the current usage and implementation of it and a general feeling for the spirit of the definition. Additionally I think the implementation makes sense as it is. The reason for NamedElements (a better name would be NameableElement) not necessarily having a name is not primarily, that tools need to save incomplete models. It rather is, that the modeler often doesn.t want to bother with a name (do you name your Include-relationsships?). If the modeler wants to refer to it in an OpaqueExpression, then she needs to use a name, and can do so since it is a NamedElement. Specifying other distinguishing attributes would for example allow to safely refer to an Include-Relationsship based on sources and targets (and be sure, that there can only be one). Is there anybody out there, who wants to do this? As it is not necessary to distinguish Model-Elements by attributes, it also is not necessary to identify these attributes. It could be necessary, if we want to express any constraints on these attributes. But nobody suggested any new constraints yet. Axel Von: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Gesendet: Mittwoch, 9. April 2014 12:35 An: Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Axel, I think you mix up distinguishability and identity which is not the same thing. Nobody said that 2 elements that are not distinguishable are the same; rather the specification says that they cannot co-exist in the same namespace. That is they are not distinguishable *for UML* only. In addition, as Nerijus pointed out, it is reasonable (and even required) that a modeling tool does not enforce all the constraints of the metamodel at all times but you should be able to check them .on demand., e.g. when you consider they should be. isDistinguishableFrom() is bugged anyway since, as specified in 2.5 it will return true for two unnamed elements of the same type. I don.t think that redefining it everywhere it is required is that painful. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 11:08 À: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-Virus-Scanned: OK From: Ed Seidewitz To: Ed Willink , "BERNARD, Yves" , Michael Chonoles , "'Axel Scheithauer'" , "'Tim Weilkiens'" CC: "uml2-rtf@omg.org" , "issues@omg.org" Subject: Re: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AFtfC6AAkXTCtcBEsbQAgH0AGWrANTzDKGZFOcBMIAAAeSQ5rA7l4D//8AzAA== Date: Wed, 9 Apr 2014 15:38:06 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [108.51.109.141] X-Virus-Scanned: amavisd-new at omg.org Ed . Name resolution from a textual language is another matter, since names are then the primary way in which certain elements can be referenced. If you need to reference a UML element from a textual element, then generally that element will need to be named, and then UML distinguishability rules will apply, so that it has a unique name within its namespace. If you need to refer to the element by a qualified name, then all of its containing namespaces also need to have names. But this is a constraint imposed by the use of the textual language referencing UML, not an inherent constraint on a UML model. For example, name resolution is discussed in some detail in sub clause 8.2 Qualified Names of the Alf spec. . Ed From: Ed Willink Date: Wednesday, April 9, 2014 at 11:26 AM To: Yves BERNARD , Michael Chonoles , Axel Scheithauer , Tim Weilkiens Cc: "uml2-rtf@omg.org" , "issues@omg.org" Subject: Re: Unnamed elements in a namespace Hi While discussing bugs in OCL we also have the related issues: It is customary to leave Operation pre/postconditions unnamed, so they are not distinguishable. Multiple Constraints may also be unnamed. Collection types are named without qualification, so Set(Boolean) and My::Set(Boolean) are not distinguishable types. Regards Ed Willink On 09/04/2014 16:06, BERNARD, Yves wrote: Yes, or rather I would say that the model is not valid if they have the same name because one of the uml::Namespace.s constraint is violated. By the way, it is not violated when both are not named but this results from a bug in the OCL specified for NamedElement::isDistinguishableFrom(). Yves De : Michael Chonoles [mailto:mjchonoles@yahoo.com] Envoyé mercredi 9 avril 2014 16:53 À: 'Axel Scheithauer'; 'Tim Weilkiens'; BERNARD, Yves Cc : uml2-rtf@omg.org; issues@omg.org Objet : RE: Unnamed elements in a namespace However, if you have 2 associations between the same ends, which is legal, and often desirable, then they both can.t be unnamed, and then they both can.t have the same name Michael From: Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Sent: Wednesday, April 09, 2014 5:08 AM To: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Subject: AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4355 / Virus Database: 3882/7318 - Release Date: 04/08/14 From: "BERNARD, Yves" To: Ed Seidewitz , Axel Scheithauer , Tim Weilkiens , Michael Chonoles CC: "uml2-rtf@omg.org" , "issues@omg.org" Date: Wed, 9 Apr 2014 17:46:16 +0200 Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAVBC8AAAAYixAAAD/bAAAASCXgAAN0PTAABP81MAACsGDgAAKR+XAACBrCgAAB/7Ug Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Ed, I think we are saying more or less the same thing: you need to use their name (or any other .visible. means) to easily distinguish between them. The purpose of the isDistinguishableFrom() operation is to check this. Otherwise it.s useless. This is why I say that: · it should be properly redefined to match the actual criteria where required (e.g. the include relationship) · There is a bug in the current OCL since two unnamed use cases are not more distinguishable than two use cases with the same name. Yves De : Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Envoyé mercredi 9 avril 2014 17:33 À: BERNARD, Yves; Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : Re: Unnamed elements in a namespace Yves . I can always tell twin from the other, because, if I shoot one, the other does not die (or, less drastically, if I put a hat on one, the other still has a bare head!). This is just a reflection of the basic concept of object identity. And all UML elements have that when represented as instances of metaclasses. Now, if I really need to tell the twins apart on sight, I can place a name tag on one with the name .Peter. and a name tag on the other with the name .John.. For my own purposes, it doesn.t really matter which I name which (as long as they don.t switch their name tags behind my back). However, it is not useful to give them the same name, because this doesn.t help me tell them apart. So, if I want to tell the twins apart by name, then I need to give them distinguishable names. But if I don.t care to name them, then it is OK for them both to be unnamed. . Ed From: , Yves BERNARD Date: Wednesday, April 9, 2014 at 8:59 AM To: Axel Scheithauer , Tim Weilkiens , Michael Chonoles Cc: "uml2-rtf@omg.org" , "issues@omg.org" Subject: RE: Unnamed elements in a namespace Axel, I think you still confuse between identity and distinguishability. Let.s try with a metaphor. Assume you are facing two .true. (and perfect) twin brothers. One is Peter and the other is John but you don.t know who is who because you have no clue about it. You can refer to one of them independently of the other because they actually have a distinct identity but you cannot know whether his is John or Peter even with a fully detailed description because they are not distinguishable. It does not make sense to speak about distinguishability when the identity is the same: if .two. items have the same identity they are obviously undistinguishable. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 14:18 À: BERNARD, Yves; Tim Weilkiens; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace Hi Yves, All Model elements are distinguishable for *UML*, no matter whether they have a name or not. In fact, to my knowledge, it is not even possible for any UML-Element to refer to the name of another element (except in an OpaqueExpression). Therefore the name isDistinguishableFrom() doesn.t make sense (or, as the discussion shows, is misleading). I agree that isDistinguishableFrom() is bugged, but the bug is it.s name. It may be difficult to investigate the original intent of this operation, but my claim is, that my suggested name is closer to it. I must admit, that this view is only supported by the current usage and implementation of it and a general feeling for the spirit of the definition. Additionally I think the implementation makes sense as it is. The reason for NamedElements (a better name would be NameableElement) not necessarily having a name is not primarily, that tools need to save incomplete models. It rather is, that the modeler often doesn.t want to bother with a name (do you name your Include-relationsships?). If the modeler wants to refer to it in an OpaqueExpression, then she needs to use a name, and can do so since it is a NamedElement. Specifying other distinguishing attributes would for example allow to safely refer to an Include-Relationsship based on sources and targets (and be sure, that there can only be one). Is there anybody out there, who wants to do this? As it is not necessary to distinguish Model-Elements by attributes, it also is not necessary to identify these attributes. It could be necessary, if we want to express any constraints on these attributes. But nobody suggested any new constraints yet. Axel Von: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Gesendet: Mittwoch, 9. April 2014 12:35 An: Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Axel, I think you mix up distinguishability and identity which is not the same thing. Nobody said that 2 elements that are not distinguishable are the same; rather the specification says that they cannot co-exist in the same namespace. That is they are not distinguishable *for UML* only. In addition, as Nerijus pointed out, it is reasonable (and even required) that a modeling tool does not enforce all the constraints of the metamodel at all times but you should be able to check them .on demand., e.g. when you consider they should be. isDistinguishableFrom() is bugged anyway since, as specified in 2.5 it will return true for two unnamed elements of the same type. I don.t think that redefining it everywhere it is required is that painful. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 11:08 À: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-Virus-Scanned: OK From: Ed Seidewitz To: "BERNARD, Yves" , Axel Scheithauer , Tim Weilkiens , "Michael Chonoles" CC: "uml2-rtf@omg.org" , "issues@omg.org" Subject: Re: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/AAVBC8AAAAYixAAAD/bAAAASCXgAAN0PTAABP81MAACsGDgAAKR+XAACBrCgAAB/7UgAAAhYIA= Date: Wed, 9 Apr 2014 16:34:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [108.51.109.141] X-Virus-Scanned: amavisd-new at omg.org Yves . No, I don.t think we are saying the same thing. I think we are saying closer to the opposite things. isDistinguishableFrom() is useful only in the context of the intended constraint on namespace members that all members that have a name be distinguishable. It is not intended to apply to unnamed members. Really. Use cases without names are not intended to be .distinguishable. in this sense at all. Of course, in the specific case of use cases, they are required to have names (by a separate constraint). But you can replace .use cases. by .associations. in your example. . Ed From: , Yves BERNARD Date: Wednesday, April 9, 2014 at 11:46 AM To: Ed Seidewitz , Axel Scheithauer , Tim Weilkiens , Michael Chonoles Cc: "uml2-rtf@omg.org" , "issues@omg.org" Subject: RE: Unnamed elements in a namespace Ed, I think we are saying more or less the same thing: you need to use their name (or any other .visible. means) to easily distinguish between them. The purpose of the isDistinguishableFrom() operation is to check this. Otherwise it.s useless. This is why I say that: · it should be properly redefined to match the actual criteria where required (e.g. the include relationship) · There is a bug in the current OCL since two unnamed use cases are not more distinguishable than two use cases with the same name. Yves De : Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Envoyé mercredi 9 avril 2014 17:33 À: BERNARD, Yves; Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : Re: Unnamed elements in a namespace Yves . I can always tell twin from the other, because, if I shoot one, the other does not die (or, less drastically, if I put a hat on one, the other still has a bare head!). This is just a reflection of the basic concept of object identity. And all UML elements have that when represented as instances of metaclasses. Now, if I really need to tell the twins apart on sight, I can place a name tag on one with the name .Peter. and a name tag on the other with the name .John.. For my own purposes, it doesn.t really matter which I name which (as long as they don.t switch their name tags behind my back). However, it is not useful to give them the same name, because this doesn.t help me tell them apart. So, if I want to tell the twins apart by name, then I need to give them distinguishable names. But if I don.t care to name them, then it is OK for them both to be unnamed. . Ed From: , Yves BERNARD Date: Wednesday, April 9, 2014 at 8:59 AM To: Axel Scheithauer , Tim Weilkiens , Michael Chonoles Cc: "uml2-rtf@omg.org" , "issues@omg.org" Subject: RE: Unnamed elements in a namespace Axel, I think you still confuse between identity and distinguishability. Let.s try with a metaphor. Assume you are facing two .true. (and perfect) twin brothers. One is Peter and the other is John but you don.t know who is who because you have no clue about it. You can refer to one of them independently of the other because they actually have a distinct identity but you cannot know whether his is John or Peter even with a fully detailed description because they are not distinguishable. It does not make sense to speak about distinguishability when the identity is the same: if .two. items have the same identity they are obviously undistinguishable. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 14:18 À: BERNARD, Yves; Tim Weilkiens; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace Hi Yves, All Model elements are distinguishable for *UML*, no matter whether they have a name or not. In fact, to my knowledge, it is not even possible for any UML-Element to refer to the name of another element (except in an OpaqueExpression). Therefore the name isDistinguishableFrom() doesn.t make sense (or, as the discussion shows, is misleading). I agree that isDistinguishableFrom() is bugged, but the bug is it.s name. It may be difficult to investigate the original intent of this operation, but my claim is, that my suggested name is closer to it. I must admit, that this view is only supported by the current usage and implementation of it and a general feeling for the spirit of the definition. Additionally I think the implementation makes sense as it is. The reason for NamedElements (a better name would be NameableElement) not necessarily having a name is not primarily, that tools need to save incomplete models. It rather is, that the modeler often doesn.t want to bother with a name (do you name your Include-relationsships?). If the modeler wants to refer to it in an OpaqueExpression, then she needs to use a name, and can do so since it is a NamedElement. Specifying other distinguishing attributes would for example allow to safely refer to an Include-Relationsship based on sources and targets (and be sure, that there can only be one). Is there anybody out there, who wants to do this? As it is not necessary to distinguish Model-Elements by attributes, it also is not necessary to identify these attributes. It could be necessary, if we want to express any constraints on these attributes. But nobody suggested any new constraints yet. Axel Von: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Gesendet: Mittwoch, 9. April 2014 12:35 An: Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Axel, I think you mix up distinguishability and identity which is not the same thing. Nobody said that 2 elements that are not distinguishable are the same; rather the specification says that they cannot co-exist in the same namespace. That is they are not distinguishable *for UML* only. In addition, as Nerijus pointed out, it is reasonable (and even required) that a modeling tool does not enforce all the constraints of the metamodel at all times but you should be able to check them .on demand., e.g. when you consider they should be. isDistinguishableFrom() is bugged anyway since, as specified in 2.5 it will return true for two unnamed elements of the same type. I don.t think that redefining it everywhere it is required is that painful. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 11:08 À: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-TCPREMOTEIP: 108.50.168.10 X-Authenticated-UID: tom@coastenterprises.com Date: Wed, 09 Apr 2014 13:02:46 -0400 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 To: Ed Seidewitz , "BERNARD, Yves" , Axel Scheithauer , Tim Weilkiens , Michael Chonoles CC: "uml2-rtf@omg.org" , "issues@omg.org" Subject: Re: Unnamed elements in a namespace X-Virus-Scanned: amavisd-new at omg.org On 4/9/2014 12:34 PM, Ed Seidewitz wrote: Yves . No, I don.t think we are saying the same thing. I think we are saying closer to the opposite things. isDistinguishableFrom() is useful only in the context of the intended constraint on namespace members that all members that have a name be distinguishable. It is not intended to apply to unnamed members. Really. In fact, as Ed already pointed out, Interactions has two classes, Gate, and Message, where the semantics of interactions requires overiding the inDistinuishableFrom operation to always assert true for instances of that class. Whether this is a "mistake" is moot at this point. We are stuck with this anomaly due to backwards compatibility requirements. Tom Use cases without names are not intended to be .distinguishable. in this sense at all. Of course, in the specific case of use cases, they are required to have names (by a separate constraint). But you can replace .use cases. by .associations. in your example. . Ed From: , Yves BERNARD Date: Wednesday, April 9, 2014 at 11:46 AM To: Ed Seidewitz , Axel Scheithauer , Tim Weilkiens , Michael Chonoles Cc: "uml2-rtf@omg.org" , "issues@omg.org" Subject: RE: Unnamed elements in a namespace Ed, I think we are saying more or less the same thing: you need to use their name (or any other .visible. means) to easily distinguish between them. The purpose of the isDistinguishableFrom() operation is to check this. Otherwise it.s useless. This is why I say that: · it should be properly redefined to match the actual criteria where required (e.g. the include relationship) · There is a bug in the current OCL since two unnamed use cases are not more distinguishable than two use cases with the same name. Yves De : Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Envoyé mercredi 9 avril 2014 17:33 À: BERNARD, Yves; Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : Re: Unnamed elements in a namespace Yves . I can always tell twin from the other, because, if I shoot one, the other does not die (or, less drastically, if I put a hat on one, the other still has a bare head!). This is just a reflection of the basic concept of object identity. And all UML elements have that when represented as instances of metaclasses. Now, if I really need to tell the twins apart on sight, I can place a name tag on one with the name .Peter. and a name tag on the other with the name .John.. For my own purposes, it doesn.t really matter which I name which (as long as they don.t switch their name tags behind my back). However, it is not useful to give them the same name, because this doesn.t help me tell them apart. So, if I want to tell the twins apart by name, then I need to give them distinguishable names. But if I don.t care to name them, then it is OK for them both to be unnamed. . Ed From: , Yves BERNARD Date: Wednesday, April 9, 2014 at 8:59 AM To: Axel Scheithauer , Tim Weilkiens , Michael Chonoles Cc: "uml2-rtf@omg.org" , "issues@omg.org" Subject: RE: Unnamed elements in a namespace Axel, I think you still confuse between identity and distinguishability. Let.s try with a metaphor. Assume you are facing two .true. (and perfect) twin brothers. One is Peter and the other is John but you don.t know who is who because you have no clue about it. You can refer to one of them independently of the other because they actually have a distinct identity but you cannot know whether his is John or Peter even with a fully detailed description because they are not distinguishable. It does not make sense to speak about distinguishability when the identity is the same: if .two. items have the same identity they are obviously undistinguishable. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 14:18 À: BERNARD, Yves; Tim Weilkiens; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace Hi Yves, All Model elements are distinguishable for *UML*, no matter whether they have a name or not. In fact, to my knowledge, it is not even possible for any UML-Element to refer to the name of another element (except in an OpaqueExpression). Therefore the name isDistinguishableFrom() doesn.t make sense (or, as the discussion shows, is misleading). I agree that isDistinguishableFrom() is bugged, but the bug is it.s name. It may be difficult to investigate the original intent of this operation, but my claim is, that my suggested name is closer to it. I must admit, that this view is only supported by the current usage and implementation of it and a general feeling for the spirit of the definition. Additionally I think the implementation makes sense as it is. The reason for NamedElements (a better name would be NameableElement) not necessarily having a name is not primarily, that tools need to save incomplete models. It rather is, that the modeler often doesn.t want to bother with a name (do you name your Include-relationsships?). If the modeler wants to refer to it in an OpaqueExpression, then she needs to use a name, and can do so since it is a NamedElement. Specifying other distinguishing attributes would for example allow to safely refer to an Include-Relationsship based on sources and targets (and be sure, that there can only be one). Is there anybody out there, who wants to do this? As it is not necessary to distinguish Model-Elements by attributes, it also is not necessary to identify these attributes. It could be necessary, if we want to express any constraints on these attributes. But nobody suggested any new constraints yet. Axel Von: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Gesendet: Mittwoch, 9. April 2014 12:35 An: Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Axel, I think you mix up distinguishability and identity which is not the same thing. Nobody said that 2 elements that are not distinguishable are the same; rather the specification says that they cannot co-exist in the same namespace. That is they are not distinguishable *for UML* only. In addition, as Nerijus pointed out, it is reasonable (and even required) that a modeling tool does not enforce all the constraints of the metamodel at all times but you should be able to check them .on demand., e.g. when you consider they should be. isDistinguishableFrom() is bugged anyway since, as specified in 2.5 it will return true for two unnamed elements of the same type. I don.t think that redefining it everywhere it is required is that painful. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 11:08 À: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 From: Tim Weilkiens To: "BERNARD, Yves" , Tom Rutt , "Ed Seidewitz" , Axel Scheithauer , Michael Chonoles CC: "uml2-rtf@omg.org" , "issues@omg.org" Subject: RE: Unnamed elements in a namespace Thread-Topic: Unnamed elements in a namespace Thread-Index: Ac9TY5d5RaWFsijtRoiKA6SPHw1Z/ADzOz7AADkkc4A= Date: Mon, 14 Apr 2014 19:23:01 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [93.203.154.129] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org Agreed! Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, April 14, 2014 3:12 PM To: Tom Rutt; Ed Seidewitz; Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Subject: RE: Unnamed elements in a namespace The mail exchange we had on this topic shows that - at least - a clarification is required but the discussion is not closed to me. Thus it makes sense to create the two issues proposed by Tim. Thanks, Yves De : Tom Rutt [mailto:tom@coastin.com] Envoyé mercredi 9 avril 2014 19:03 À: Ed Seidewitz; BERNARD, Yves; Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : Re: Unnamed elements in a namespace On 4/9/2014 12:34 PM, Ed Seidewitz wrote: Yves . No, I don.t think we are saying the same thing. I think we are saying closer to the opposite things. isDistinguishableFrom() is useful only in the context of the intended constraint on namespace members that all members that have a name be distinguishable. It is not intended to apply to unnamed members. Really. In fact, as Ed already pointed out, Interactions has two classes, Gate, and Message, where the semantics of interactions requires overiding the inDistinuishableFrom operation to always assert true for instances of that class. Whether this is a "mistake" is moot at this point. We are stuck with this anomaly due to backwards compatibility requirements. Tom Use cases without names are not intended to be .distinguishable. in this sense at all. Of course, in the specific case of use cases, they are required to have names (by a separate constraint). But you can replace .use cases. by .associations. in your example. . Ed From: , Yves BERNARD Date: Wednesday, April 9, 2014 at 11:46 AM To: Ed Seidewitz , Axel Scheithauer , Tim Weilkiens , Michael Chonoles Cc: "uml2-rtf@omg.org" , "issues@omg.org" Subject: RE: Unnamed elements in a namespace Ed, I think we are saying more or less the same thing: you need to use their name (or any other .visible. means) to easily distinguish between them. The purpose of the isDistinguishableFrom() operation is to check this. Otherwise it.s useless. This is why I say that: · it should be properly redefined to match the actual criteria where required (e.g. the include relationship) · There is a bug in the current OCL since two unnamed use cases are not more distinguishable than two use cases with the same name. Yves De : Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Envoyé mercredi 9 avril 2014 17:33 À: BERNARD, Yves; Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : Re: Unnamed elements in a namespace Yves . I can always tell twin from the other, because, if I shoot one, the other does not die (or, less drastically, if I put a hat on one, the other still has a bare head!). This is just a reflection of the basic concept of object identity. And all UML elements have that when represented as instances of metaclasses. Now, if I really need to tell the twins apart on sight, I can place a name tag on one with the name .Peter. and a name tag on the other with the name .John.. For my own purposes, it doesn.t really matter which I name which (as long as they don.t switch their name tags behind my back). However, it is not useful to give them the same name, because this doesn.t help me tell them apart. So, if I want to tell the twins apart by name, then I need to give them distinguishable names. But if I don.t care to name them, then it is OK for them both to be unnamed. . Ed From: , Yves BERNARD Date: Wednesday, April 9, 2014 at 8:59 AM To: Axel Scheithauer , Tim Weilkiens , Michael Chonoles Cc: "uml2-rtf@omg.org" , "issues@omg.org" Subject: RE: Unnamed elements in a namespace Axel, I think you still confuse between identity and distinguishability. Let.s try with a metaphor. Assume you are facing two .true. (and perfect) twin brothers. One is Peter and the other is John but you don.t know who is who because you have no clue about it. You can refer to one of them independently of the other because they actually have a distinct identity but you cannot know whether his is John or Peter even with a fully detailed description because they are not distinguishable. It does not make sense to speak about distinguishability when the identity is the same: if .two. items have the same identity they are obviously undistinguishable. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 14:18 À: BERNARD, Yves; Tim Weilkiens; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace Hi Yves, All Model elements are distinguishable for *UML*, no matter whether they have a name or not. In fact, to my knowledge, it is not even possible for any UML-Element to refer to the name of another element (except in an OpaqueExpression). Therefore the name isDistinguishableFrom() doesn.t make sense (or, as the discussion shows, is misleading). I agree that isDistinguishableFrom() is bugged, but the bug is it.s name. It may be difficult to investigate the original intent of this operation, but my claim is, that my suggested name is closer to it. I must admit, that this view is only supported by the current usage and implementation of it and a general feeling for the spirit of the definition. Additionally I think the implementation makes sense as it is. The reason for NamedElements (a better name would be NameableElement) not necessarily having a name is not primarily, that tools need to save incomplete models. It rather is, that the modeler often doesn.t want to bother with a name (do you name your Include-relationsships?). If the modeler wants to refer to it in an OpaqueExpression, then she needs to use a name, and can do so since it is a NamedElement. Specifying other distinguishing attributes would for example allow to safely refer to an Include-Relationsship based on sources and targets (and be sure, that there can only be one). Is there anybody out there, who wants to do this? As it is not necessary to distinguish Model-Elements by attributes, it also is not necessary to identify these attributes. It could be necessary, if we want to express any constraints on these attributes. But nobody suggested any new constraints yet. Axel Von: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Gesendet: Mittwoch, 9. April 2014 12:35 An: Axel Scheithauer; Tim Weilkiens; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Axel, I think you mix up distinguishability and identity which is not the same thing. Nobody said that 2 elements that are not distinguishable are the same; rather the specification says that they cannot co-exist in the same namespace. That is they are not distinguishable *for UML* only. In addition, as Nerijus pointed out, it is reasonable (and even required) that a modeling tool does not enforce all the constraints of the metamodel at all times but you should be able to check them .on demand., e.g. when you consider they should be. isDistinguishableFrom() is bugged anyway since, as specified in 2.5 it will return true for two unnamed elements of the same type. I don.t think that redefining it everywhere it is required is that painful. Yves De : Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Envoyé mercredi 9 avril 2014 11:08 À: Tim Weilkiens; BERNARD, Yves; Michael Chonoles Cc : uml2-rtf@omg.org; issues@omg.org Objet : AW: Unnamed elements in a namespace I don.t agree. The only issues I see are: - The name isDistinguishableFrom() is misleading. It should get changed to something like isAllowedInTheSameNamespace() or isDistinguishableByNameIfItHasOne(;-). This includes of course the variants of this name (members_distinguishable.). - The treatment of unnamed NamedElements in a namespace should be mentioned explicitely: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name (those that have one, that is).. P. 42 .A Namespace may contain any number of unnamed NamedElements. Since they don.t have a name, they cannot be referred to by name. However, as any element in a model, they have a unique identity and can be referred to by it. This is even the standard way of referring to an element (with or without a name). The only way to refer to an element by name is in an Opaque Expression (in any language, including OCL).. p. 21 My rationale: NamedElements may have a name. That means it is possible that a namespace contains elements that don.t have a name. That is absolutely necessary, since often I don.t care for the name of the element (include-Relationsships, incomplete models,.). Therefore the constraint members_distinguishable must allow elements without name. The Elements are anyway always distinguishable, since Instances of Classes have an identity independent of their attributes. To redefine isDistinguishableFrom for all subclasses of NamedElement would make it necessary to think of all possible sets of attributes, that must be unique. For include-Relationsships it might be the source and target. But I expect that in many cases it will not be so easy. I think it is not worth the effort (and would be a pain in the ass for the tool vendors). By the way, the only MetaClasses that override it today are BehavioralFeature (takes the parameters into account), Gate and Message (simply return true in all cases). Another NamedElement that doesn.t have to be identifiable by name is Action (by virtue of not being member of a namespace). There is one case, where it should get redefined: - Associations should be allowed to have the same name. They can get distinguished by their member-Ends. I don.t see a reason, why Associations connecting different properties should not have the same name. I often use a verb like .works for. for an association between .employee. and .employer.. The same name could be used between .consultant. and .client.. Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 9. April 2014 08:13 An: BERNARD, Yves; Michael Chonoles Cc: uml2-rtf@omg.org; issues@omg.org Betreff: RE: Unnamed elements in a namespace Michael, Yves, Thanks for your responses. The conclusion of our discussion raises two issues: 1. The informal description of a Namespace must be revised. The identification of members is not based on the name, but on the query isDistinguishableFrom() of the contained NamedElements. 2. Subclasses of NamedElement must redefine the query isDistinguishableFrom() to add specific conditions, e.g. the source and target properties of the include relationship. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 8:06 AM To: Tim Weilkiens Subject: RE: Unnamed elements in a namespace Tim, IsDistinguishableFrom() is defined by the NamedElement metaclass, not by the Namespaces one and can (should.) be redefined. The formal constraint applicable to a Namespace is that all its members shall be distinguishable (see its Constraint subclause) The sentence you quoted is extracted from the informal .description. subclause and should be revised because it is not correct. Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mercredi 9 avril 2014 07:58 À: BERNARD, Yves; uml2-rtf@omg.org Objet : RE: Unnamed elements in a namespace Hi Yves, That clarifies my issue with the include relationship and raises another issue for the definition of a namespace: .A Namespace is an Element in a model that owns and/or imports a set of NamedElements that can be identified by name.. It is not only the name if we redefine the query isDistinguishableFrom() by adding for example source and targets for directed relationships. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, April 09, 2014 7:53 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: Unnamed elements in a namespace Hi Tim, These two include relationships are distinguishable as long as they have distinct targets. I think this is why your tool return .true.. The point is that isDistinguishableFrom() should formally be redefined in the spec, what is not the case currently for most (all?) of the metaclasses specialized from NamedElement. It.s worth creating an issue for this. Cheers, Yves De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé mardi 8 avril 2014 21:49 À: uml2-rtf@omg.org Objet : Unnamed elements in a namespace I.ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name. NamedElement defines the query isDistinguishableFrom(): --- isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names. body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() --- If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view. Is that an issue or did I miss something? Tim Tim Weilkiens (CEO oose) Consulting & Training oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Tim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: info@oose.de The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.