Issue 18650: Inheriting Connectors (uml25-ftf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Revision Severity: Summary: If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram attached Resolution: Revised Text: Actions taken: April 10, 2013: received issue Discussion: End of Annotations:===== ted-NM: yes From: Nerijus Jankevicius Subject: Inheriting Connectors Date: Wed, 10 Apr 2013 15:22:02 +0300 Cc: Robert Karban , DELP , Tim Weilkiens To: uml25-ftf@omg.org, "sysml-rtf@omg.org (sysml-rtf@omg.org)" X-Mailer: Apple Mail (2.1085) X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Qr0dekVU X-Brightmail-Tracker: AAAAAA== Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Screen shot 2013-04-10 at 3.14.27 PM.png Thanks, Nerijus From: Tim Weilkiens To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , "nerijus@nomagic.com" CC: "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: Ac415zQp1Ix4v5jShkyeuxACfqj10Q== Date: Wed, 10 Apr 2013 12:30:36 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Qr0delmo X-Brightmail-Tracker: AAAAAA== I think that the connector ab is inherited. Unfortunately it is not connected with a1, but with part of a that is not visible in the inherited context. Connector ab is in an undefined state. That's an SysML or UML issue. Tim -----Original Message----- From: Nerijus Jankevicius [nerijus@nomagic.com] Received: Mittwoch, 10 Apr. 2013, 14:22 To: uml25-ftf@omg.org [uml25-ftf@omg.org]; sysml-rtf@omg.org (sysml-rtf@omg.org) [sysml-rtf@omg.org] CC: Robert Karban [Robert.Karban@jpl.nasa.gov]; DELP [Christopher.L.Delp@nasa.gov]; Tim Weilkiens [Tim.Weilkiens@oose.de] Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus ----------------------------------------------------------------- oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Geschäsfü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 Der Inhalt dieser E-Mail ist nur fü Empfäer und nicht zur Veröntlichung oder unautorisierten Weitergabe bestimmt. From: Steve Cook To: Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , "nerijus@nomagic.com" CC: "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: Ac415zQp1RDuh+9veE6Bgo6AnrLUuAAAL7hA Date: Wed, 10 Apr 2013 12:55:28 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(189002)(199002)(47976001)(16406001)(221733001)(46102001)(54356001)(71186001)(65816001)(49866001)(59766001)(18277545001)(76482001)(512874001)(69226001)(77982001)(56816002)(47446002)(55846006)(80022001)(31966008)(44976002)(33656001)(56776001)(79102001)(18276755001)(54316002)(63696002)(51856001)(20776003)(50986001)(74662001)(81342001)(4396001)(74502001)(53806001)(81542001)(564824004)(47736001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB010;H:TK5EX14HUBC106.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0812095267 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== I think I agree. Here is how I would say it, from a UML perspective: The connector ab is a feature of the class Context, and as such is inherited in Context., independently of the redefinitions of the Properties. But since a has been redefined in Context., it is not inherited. So any attempt to use ab in Context. will lead to something undesirable. I guess the idea of .using ab in Context.. might turn into a question about the semantics of LinkActions, in cases where ab is typed by an Association. I don.t think that Actions really handle Connectors, though. There is no connector between a1 and b. If you wanted to create one, you.d have to decide whether to redefine ab or not. Given that not redefining it leads to something undesirable, it would probably be a good idea to do so. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 10 April 2013 13:31 To: uml25-ftf@omg.org; sysml-rtf@omg.org; nerijus@nomagic.com Cc: Robert.Karban@jpl.nasa.gov; Christopher.L.Delp@nasa.gov Subject: RE: Inheriting Connectors I think that the connector ab is inherited. Unfortunately it is not connected with a1, but with part of a that is not visible in the inherited context. Connector ab is in an undefined state. That's an SysML or UML issue. Tim -----Original Message----- From: Nerijus Jankevicius [nerijus@nomagic.com] Received: Mittwoch, 10 Apr. 2013, 14:22 To: uml25-ftf@omg.org [uml25-ftf@omg.org]; sysml-rtf@omg.org (sysml-rtf@omg.org) [sysml-rtf@omg.org] CC: Robert Karban [Robert.Karban@jpl.nasa.gov]; DELP [Christopher.L.Delp@nasa.gov]; Tim Weilkiens [Tim.Weilkiens@oose.de] Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus ----------------------------------------------------------------- oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Geschäsfü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 Der Inhalt dieser E-Mail ist nur fü Empfäer und nicht zur Veröntlichung oder unautorisierten Weitergabe bestimmt. Subject: RE: Inheriting Connectors X-KeepSent: AE607671:428AF8DF-C2257B49:00476CD5; type=4; name=$KeepSent To: Steve Cook Cc: "Christopher.L.Delp@nasa.gov" , "nerijus@nomagic.com" , "Robert.Karban@jpl.nasa.gov" , "sysml-rtf@omg.org" , Tim Weilkiens , "uml25-ftf@omg.org" X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Eran Gery Date: Wed, 10 Apr 2013 16:04:26 +0300 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.3FP2 ZX853FP2HF3|December 12, 2012) at 10/04/2013 16:04:17 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13041013-5024-0000-0000-000005B4E26F X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3AD593w021338 X-Brightmail-Tracker: AAAAAh15Qr0deRqa X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Steve, Hi... been long time... That would be a reuse disaster. Leaving the deep technicalities aside (and I am not sure if there are such), you do not want to invalidate a system structure every time you refine a part. I did not look into the metamodel technicalities but that would definitely be an undesired outcome, so better is to find way to make it work. Eran Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Steve Cook To: Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , "nerijus@nomagic.com" , Cc: "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" Date: 10/04/2013 03:56 PM Subject: RE: Inheriting Connectors I think I agree. Here is how I would say it, from a UML perspective: The connector ab is a feature of the class Context, and as such is inherited in Context., independently of the redefinitions of the Properties. But since a has been redefined in Context., it is not inherited. So any attempt to use ab in Context. will lead to something undesirable. I guess the idea of .using ab in Context.. might turn into a question about the semantics of LinkActions, in cases where ab is typed by an Association. I don.t think that Actions really handle Connectors, though. There is no connector between a1 and b. If you wanted to create one, you.d have to decide whether to redefine ab or not. Given that not redefining it leads to something undesirable, it would probably be a good idea to do so. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 10 April 2013 13:31 To: uml25-ftf@omg.org; sysml-rtf@omg.org; nerijus@nomagic.com Cc: Robert.Karban@jpl.nasa.gov; Christopher.L.Delp@nasa.gov Subject: RE: Inheriting Connectors I think that the connector ab is inherited. Unfortunately it is not connected with a1, but with part of a that is not visible in the inherited context. Connector ab is in an undefined state. That's an SysML or UML issue. Tim -----Original Message----- From: Nerijus Jankevicius [nerijus@nomagic.com] Received: Mittwoch, 10 Apr. 2013, 14:22 To: uml25-ftf@omg.org [uml25-ftf@omg.org]; sysml-rtf@omg.org ( sysml-rtf@omg.org) [sysml-rtf@omg.org] CC: Robert Karban [Robert.Karban@jpl.nasa.gov]; DELP [Christopher.L.Delp@nasa.gov]; Tim Weilkiens [Tim.Weilkiens@oose.de] Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus ----------------------------------------------------------------- oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Geschäsfü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 Der Inhalt dieser E-Mail ist nur fü Empfäer und nicht zur Veröntlichung oder unautorisierten Weitergabe bestimmt. From: "Delp, Christopher L (313K)" To: Nerijus Jankevicius CC: "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "Karban, Robert (3101-Affiliate)" , DELP , "Tim Weilkiens" Subject: Re: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeYKO1tnGzreskqxvIHAPEDKGpjPdiOJ Date: Wed, 10 Apr 2013 13:40:31 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-Source-Sender: Christopher.L.Delp@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== My $0.02 Connectors should be treated as parts as well. Unless they are redefined they should be inherited. <> Chris Delp Systems Architect NASA JPL On Apr 10, 2013, at 5:22 AM, "Nerijus Jankevicius" wrote: Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus Screen shot 2013-04-10 at 3.14.27 PM.png From: Steve Cook To: Eran Gery CC: "Christopher.L.Delp@nasa.gov" , "nerijus@nomagic.com" , "Robert.Karban@jpl.nasa.gov" , "sysml-rtf@omg.org" , "Tim Weilkiens" , "uml25-ftf@omg.org" Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: Ac415zQp1RDuh+9veE6Bgo6AnrLUuAAAL7hAAAD+owAAAf+8gA== Date: Wed, 10 Apr 2013 14:05:29 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(199002)(189002)(65816001)(47446002)(16406001)(53806001)(74502001)(56816002)(56776001)(47776003)(621065001)(54356001)(31966008)(44976002)(46102001)(81542001)(51856001)(59766001)(47976001)(49866001)(81342001)(79102001)(4396001)(20776003)(47736001)(63696002)(50986001)(76482001)(54316002)(221733001)(33656001)(73894001)(69226001)(80022001)(74662001)(77982001)(23676001)(50466001)(55846006);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB026;H:TK5EX14MLTC104.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0812095267 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3AE72Hu028677 X-Brightmail-Tracker: AAAAAh15Qr0deRqa X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Eran Just to be clear, my message was not in any way intended as a proposal for how things should be. It was intended as a clarification of how they are, based on the current UML specification. I have no doubt that the situation could be greatly improved. -- Steve -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: 10 April 2013 14:04 To: Steve Cook Cc: Christopher.L.Delp@nasa.gov; nerijus@nomagic.com; Robert.Karban@jpl.nasa.gov; sysml-rtf@omg.org; Tim Weilkiens; uml25-ftf@omg.org Subject: RE: Inheriting Connectors Steve, Hi... been long time... That would be a reuse disaster. Leaving the deep technicalities aside (and I am not sure if there are such), you do not want to invalidate a system structure every time you refine a part. I did not look into the metamodel technicalities but that would definitely be an undesired outcome, so better is to find way to make it work. Eran Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Steve Cook To: Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , "nerijus@nomagic.com" , Cc: "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" Date: 10/04/2013 03:56 PM Subject: RE: Inheriting Connectors I think I agree. Here is how I would say it, from a UML perspective: The connector ab is a feature of the class Context, and as such is inherited in Context., independently of the redefinitions of the Properties. But since a has been redefined in Context., it is not inherited. So any attempt to use ab in Context. will lead to something undesirable. I guess the idea of .using ab in Context.. might turn into a question about the semantics of LinkActions, in cases where ab is typed by an Association. I don.t think that Actions really handle Connectors, though. There is no connector between a1 and b. If you wanted to create one, you.d have to decide whether to redefine ab or not. Given that not redefining it leads to something undesirable, it would probably be a good idea to do so. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 10 April 2013 13:31 To: uml25-ftf@omg.org; sysml-rtf@omg.org; nerijus@nomagic.com Cc: Robert.Karban@jpl.nasa.gov; Christopher.L.Delp@nasa.gov Subject: RE: Inheriting Connectors I think that the connector ab is inherited. Unfortunately it is not connected with a1, but with part of a that is not visible in the inherited context. Connector ab is in an undefined state. That's an SysML or UML issue. Tim -----Original Message----- From: Nerijus Jankevicius [nerijus@nomagic.com] Received: Mittwoch, 10 Apr. 2013, 14:22 To: uml25-ftf@omg.org [uml25-ftf@omg.org]; sysml-rtf@omg.org ( sysml-rtf@omg.org) [sysml-rtf@omg.org] CC: Robert Karban [Robert.Karban@jpl.nasa.gov]; DELP [Christopher.L.Delp@nasa.gov]; Tim Weilkiens [Tim.Weilkiens@oose.de] Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus ----------------------------------------------------------------- oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 GeschäsfüTim Weilkiens Fon: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=5ZH2umiBntPgQHW44mDeDgrnU2hc5HDoJgvuL5pMTjU=; b=NhF6CswzIuMoefQkXVXFdxpJClhyG9Sn+6lhzvg/ubIefYFYAp7pRi5KBzr1jlwa9l BZmGTQpvO5kMTd3oCETik/ah3WlfiPocET5/v9NinHtGKgh2PAgqF6qOlMhCzmOTv/Wk upT8uytxhzlMqyB51meVoa6PLKd8mPrvdHMGkpmgg2bMsKGoX0oEGyLYfeQfXs4U0eYh OnavPVyj4hiwtG1KPDZl/BCP6hkxbeT0o3NB3cwV+wxaRmdkBgZa8vdxjYmCATDlt3r7 7iUEtaEpV6rOsXwou6Zbpr4WJ7bjsOHx7W2rXoyzbgyhd7LgCeq1jEPyvKZ3ryofThv3 FP3Q== X-Received: by 10.52.178.1 with SMTP id cu1mr1340493vdc.97.1365603242760; Wed, 10 Apr 2013 07:14:02 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 10 Apr 2013 10:13:22 -0400 X-Google-Sender-Auth: 1QSURLytKWISWmR5mFsE3FCkCoo Subject: Re: Inheriting Connectors To: "Delp, Christopher L (313K)" Cc: Nerijus Jankevicius , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== I fully agree with Eran. We should look at the problem primarily from a user perspective. I've had over 20 years experience with this type of structure modeling and, based on that, users expect the inherited connector to be reconnected to the redefined part. If language is an issue, a tool can make it work that way. Bran On Wed, Apr 10, 2013 at 9:40 AM, Delp, Christopher L (313K) wrote: My $0.02 Connectors should be treated as parts as well. Unless they are redefined they should be inherited. <> Chris Delp Systems Architect NASA JPL On Apr 10, 2013, at 5:22 AM, "Nerijus Jankevicius" wrote: Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus From: "BERNARD, Yves" To: Bran Selic , "Delp, Christopher L (313K)" CC: Nerijus Jankevicius , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens Date: Wed, 10 Apr 2013 16:22:12 +0200 Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: Ac419eK7IXAda3rpQpmwaLGeOT16sAAAEYFA 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 X-Brightmail-Tracker: AAAAAgr+n5EdeUK9 X-Brightmail-Tracker: AAAAAA== Hi Bran, I agree with the intent, the point is that, as defined today, I think that there are the right constraints on the redefinition today to make sure this reconnection will make sense in all cases. Yves From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: mercredi 10 avril 2013 16:13 To: Delp, Christopher L (313K) Cc: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org); Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens Subject: Re: Inheriting Connectors I fully agree with Eran. We should look at the problem primarily from a user perspective. I've had over 20 years experience with this type of structure modeling and, based on that, users expect the inherited connector to be reconnected to the redefined part. If language is an issue, a tool can make it work that way. Bran On Wed, Apr 10, 2013 at 9:40 AM, Delp, Christopher L (313K) wrote: My $0.02 Connectors should be treated as parts as well. Unless they are redefined they should be inherited. <> Chris Delp Systems Architect NASA JPL On Apr 10, 2013, at 5:22 AM, "Nerijus Jankevicius" wrote: Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus 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: "Bock, Conrad" To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" CC: "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" Date: Wed, 10 Apr 2013 10:24:50 -0400 Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: Ac415zQp1Ix4v5jShkyeuxACfqj10QAD5irw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3AEPHSs031409 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Tim, et al, > I think that the connector ab is inherited. Unfortunately it is not connected > with a1, but with part of a that is not visible in the inherited context. > Connector ab is in an undefined state. That's an SysML or UML issue. What if the redefinition of property "a" in Context' was also named "a"? Conrad DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=OvCsmtkJ51znZZuriCFdV7NSM1C4YNRZ7z4CpiCcZOE=; b=MY7uu4HA8iYdjq0/nBcNYUCkEfGXss8isThUxqFKX72vPTa5k1STPLpfBHmQCRzwZq vMrwkVYuBi2rpg8/oaTNNsUWLFcXCSaV6Kmf+6zot+t6BtLC5HdDLiZSnHtOfx/YHDfL xc+XSJWAJN48qyt0F41ltsJI30n3YCVnC+d4VPDd6PTY5xmZyat36avvbQhn2dVnZD6a o2zIJPWH+S4LZmW0u7fieZRPNrZUT5vNy/j1Ki48uzMvBvR544GehAQ7U45sRW7wifUX nFgFP3/DiYcOrfwXYddBGyDWjJfTZVp8v+RSvwOb/2vC0xnZW+xbG/c/qgDvLDVSnLwP tKyw== X-Received: by 10.52.178.1 with SMTP id cu1mr1379899vdc.97.1365604111983; Wed, 10 Apr 2013 07:28:31 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 10 Apr 2013 10:27:51 -0400 X-Google-Sender-Auth: sTIw6z1HaPu2M1zDKhgsGj1IfIc Subject: Re: Inheriting Connectors To: "Bock, Conrad" Cc: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== As for the notation, the inherited connector should use the same notation as any inherited part in a structure. Currently, this is chosen by tool vendors. For example, inherited parts and connectors might be shown using grey or dotted lines. Perhaps we should try to define a default rendering? Bran On Wed, Apr 10, 2013 at 10:24 AM, Bock, Conrad wrote: Tim, et al, > I think that the connector ab is inherited. Unfortunately it is not connected > with a1, but with part of a that is not visible in the inherited context. > Connector ab is in an undefined state. That's an SysML or UML issue. What if the redefinition of property "a" in Context' was also named "a"? Conrad DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=r18fFm1C9YQhcC9uAy1m8fu+GTqVKbDmatrccyaZrcA=; b=h+bQXm9TYf89oyVznle2eg3er3BkLJAKHcO0kRSFzFWYm5hc9qSoPAbOTMZvEWjEtF jnLWUG3/Ao+XTYBwlPiF9B+uRB0GpRnPVfz/gwWGYQeX6j4ygpebx0EC+fy18OabAsQp dm7gi9Fd3byq3BuXvjKMrV/BZVhmC1YeRRacxlXLvrUGTUHmbfY4jxIH3KzJcu+VBFST ULb2WP1P4jZQ0l2/KPuyIzYsN428YKlwIgM2h4C5PEhe/uGdGgtdBSfiiJw4HjRrRcnz 2a8m6ZpYSKugFUqMV8w37vw9QRUDshOxdT/5nclMPXE2oNJK3bHMi6EqWy7HhajV0G24 hebA== X-Received: by 10.52.119.175 with SMTP id kv15mr1443694vdb.23.1365604278610; Wed, 10 Apr 2013 07:31:18 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 10 Apr 2013 10:30:37 -0400 X-Google-Sender-Auth: A7cAlI3IhtVBFStowSyRDHEfWpk Subject: Re: Inheriting Connectors To: "BERNARD, Yves" Cc: "Delp, Christopher L (313K)" , Nerijus Jankevicius , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== Yves, I am not sure it is necessary for it to make sense in all possible cases, but at least the expected ones. Bran On Wed, Apr 10, 2013 at 10:22 AM, BERNARD, Yves wrote: Hi Bran, I agree with the intent, the point is that, as defined today, I think that there are the right constraints on the redefinition today to make sure this reconnection will make sense in all cases. Yves From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: mercredi 10 avril 2013 16:13 To: Delp, Christopher L (313K) Cc: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org); Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens Subject: Re: Inheriting Connectors I fully agree with Eran. We should look at the problem primarily from a user perspective. I've had over 20 years experience with this type of structure modeling and, based on that, users expect the inherited connector to be reconnected to the redefined part. If language is an issue, a tool can make it work that way. Bran On Wed, Apr 10, 2013 at 9:40 AM, Delp, Christopher L (313K) wrote: My $0.02 Connectors should be treated as parts as well. Unless they are redefined they should be inherited. <> Chris Delp Systems Architect NASA JPL On Apr 10, 2013, at 5:22 AM, "Nerijus Jankevicius" wrote: Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus 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: Juergen Boldt , Nerijus Jankevicius , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" CC: Robert Karban , DELP , Tim Weilkiens Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeZEo3vx/ZEABUWII2I9lAcq25jPxAiA///AGjA= Date: Wed, 10 Apr 2013 14:33:41 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.48.209.197] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAx15Qr0deRpsHXpZqA== X-Brightmail-Tracker: AAAAAA== OK, everybody. As often happens, have had this discussion before, toward the end of last year. Please see Issues 18132 and 18171. I can also forward more of the old email thread. From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, April 10, 2013 9:19 AM To: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Re: Inheriting Connectors issue? -Juergen At 08:22 AM 4/10/2013, Nerijus Jankevicius wrote: Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] X-Trusted-NM: yes Subject: Re: Inheriting Connectors From: Nerijus Jankevicius Date: Wed, 10 Apr 2013 17:34:04 +0300 Cc: "Bock, Conrad" , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" To: Bran Selic X-Mailer: Apple Mail (2.1085) X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Bran, Notation for inherited is one thing. But relation which is displayed as attached to wrong "box" (other than end in the model) is other thing. Nerijus On Apr 10, 2013, at 5:27 PM, Bran Selic wrote: As for the notation, the inherited connector should use the same notation as any inherited part in a structure. Currently, this is chosen by tool vendors. For example, inherited parts and connectors might be shown using grey or dotted lines. Perhaps we should try to define a default rendering? Bran On Wed, Apr 10, 2013 at 10:24 AM, Bock, Conrad wrote: Tim, et al, > I think that the connector ab is inherited. Unfortunately it is not connected > with a1, but with part of a that is not visible in the inherited context. > Connector ab is in an undefined state. That's an SysML or UML issue. What if the redefinition of property "a" in Context' was also named "a"? Conrad From: Steve Cook To: "BERNARD, Yves" , Bran Selic , "Delp, Christopher L (313K)" CC: Nerijus Jankevicius , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "Karban, Robert (3101-Affiliate)" , DELP , "Tim Weilkiens" Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeaT1RDuh+9veE6Bgo6AnrLUuAAAEYFAmM+C2KA= Date: Wed, 10 Apr 2013 14:34:54 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(164054002)(377424002)(377454001)(365934001)(24454001)(51444002)(189002)(199002)(5343655001)(47976001)(16406001)(221733001)(46102001)(54356001)(71186001)(65816001)(49866001)(59766001)(18277545001)(76482001)(69226001)(16236675001)(5343635001)(15202345001)(77982001)(512954001)(47446002)(55846006)(80022001)(31966008)(44976002)(56776001)(33656001)(79102001)(56816002)(54316002)(51856001)(50986001)(20776003)(63696002)(74662001)(18276755001)(74502001)(4396001)(564824004)(53806001)(81342001)(81542001)(47736001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB010;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0812095267 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== Bran said .users expect the inherited connector to be reconnected to the redefined part.. No; the inherited connector is connected to the part it is connected to, whether inherited or not. I think what Bran intended to say was .users expect the inherited connector to be redefined, and the redefined connector to be connected to the redefined part.. Yves said .I think that there are the right constraints on the redefinition today.. No; in UML there are no such constraints. Maybe this conversation is saying there should be. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 April 2013 15:22 To: Bran Selic; Delp, Christopher L (313K) Cc: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org); Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens Subject: RE: Inheriting Connectors Hi Bran, I agree with the intent, the point is that, as defined today, I think that there are the right constraints on the redefinition today to make sure this reconnection will make sense in all cases. Yves From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: mercredi 10 avril 2013 16:13 To: Delp, Christopher L (313K) Cc: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org); Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens Subject: Re: Inheriting Connectors I fully agree with Eran. We should look at the problem primarily from a user perspective. I've had over 20 years experience with this type of structure modeling and, based on that, users expect the inherited connector to be reconnected to the redefined part. If language is an issue, a tool can make it work that way. Bran On Wed, Apr 10, 2013 at 9:40 AM, Delp, Christopher L (313K) wrote: My $0.02 Connectors should be treated as parts as well. Unless they are redefined they should be inherited. <> Chris Delp Systems Architect NASA JPL On Apr 10, 2013, at 5:22 AM, "Nerijus Jankevicius" wrote: Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus 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=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=iXvr4LlEZVBHri9guaDNrC7jDgrg7wadXoZxSjv8TdI=; b=mKMAKiWO87vPHe4Bquzfxng30cnPhUAN4OuSNYsNNMXLE2PBNcLkpAhq4zMiaIvU9Q iUZHFKlbGvp2XWYF2f+B21bvZVB8y2VgdeZRpHujFOac/4jKz6per08WVuYSrGepgOHM V3gd7u3o6lkwNUZ1tJEbiSXc0dFCe7HjYVpkRxhe1YrtUWhzNw9ZDd6uQrfki0Va3WcF 5woHLerGCAboqM4tKN2AOq2zVR5y/cC1quMpEoKNUzOsqFgqrTcpaFhToJS20d3Pn2QF zykNG6ghfVK/JNgPiH2Y6i1bopsCbA7/CGIgzQiXpvKDqHoItqrvlpqWYfDbC2D3MRQw MoFA== X-Received: by 10.220.8.75 with SMTP id g11mr1684309vcg.60.1365605297092; Wed, 10 Apr 2013 07:48:17 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 10 Apr 2013 10:47:36 -0400 X-Google-Sender-Auth: Nm3w0Sz6Z2-8XzxI6ZbpHgVjK9U Subject: Re: Inheriting Connectors To: Steve Cook Cc: "BERNARD, Yves" , "Delp, Christopher L (313K)" , Nerijus Jankevicius , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== Steve, I think you are right in saying that the connector will also need to be redefined (necessitated by how connectors are defined in the metamodel). Users, of course, don't really care how it is done as long as the system behaves the way they expect. We have a choice of leaving it up to tools to deal with this or adding constraints to the metamodel that force the redefinition. Bran On Wed, Apr 10, 2013 at 10:34 AM, Steve Cook wrote: Bran said .users expect the inherited connector to be reconnected to the redefined part.. No; the inherited connector is connected to the part it is connected to, whether inherited or not. I think what Bran intended to say was .users expect the inherited connector to be redefined, and the redefined connector to be connected to the redefined part.. Yves said .I think that there are the right constraints on the redefinition today.. No; in UML there are no such constraints. Maybe this conversation is saying there should be. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 April 2013 15:22 To: Bran Selic; Delp, Christopher L (313K) Cc: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org); Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens Subject: RE: Inheriting Connectors Hi Bran, I agree with the intent, the point is that, as defined today, I think that there are the right constraints on the redefinition today to make sure this reconnection will make sense in all cases. Yves From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: mercredi 10 avril 2013 16:13 To: Delp, Christopher L (313K) Cc: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org); Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens Subject: Re: Inheriting Connectors I fully agree with Eran. We should look at the problem primarily from a user perspective. I've had over 20 years experience with this type of structure modeling and, based on that, users expect the inherited connector to be reconnected to the redefined part. If language is an issue, a tool can make it work that way. Bran On Wed, Apr 10, 2013 at 9:40 AM, Delp, Christopher L (313K) wrote: My $0.02 Connectors should be treated as parts as well. Unless they are redefined they should be inherited. <> Chris Delp Systems Architect NASA JPL On Apr 10, 2013, at 5:22 AM, "Nerijus Jankevicius" wrote: Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus 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: Steve Cook , Bran Selic , "Delp, Christopher L (313K)" CC: Nerijus Jankevicius , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens Date: Wed, 10 Apr 2013 16:49:33 +0200 Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeaT1RDuh+9veE6Bgo6AnrLUuAAAEYFAmM+C2KCAAAVb8A== 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 X-Brightmail-Tracker: AAAAAgr+n5EdeUK9 X-Brightmail-Tracker: AAAAAA== Oh, yes sorry, I wrote the opposite of what I had in mind by forgetting the .not.. You should read: .I think that they are NOT the right constraints on the redefinition today.. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: mercredi 10 avril 2013 16:35 To: BERNARD, Yves; Bran Selic; Delp, Christopher L (313K) Cc: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org); Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens Subject: RE: Inheriting Connectors Bran said .users expect the inherited connector to be reconnected to the redefined part.. No; the inherited connector is connected to the part it is connected to, whether inherited or not. I think what Bran intended to say was .users expect the inherited connector to be redefined, and the redefined connector to be connected to the redefined part.. Yves said .I think that there are the right constraints on the redefinition today.. No; in UML there are no such constraints. Maybe this conversation is saying there should be. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 April 2013 15:22 To: Bran Selic; Delp, Christopher L (313K) Cc: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org); Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens Subject: RE: Inheriting Connectors Hi Bran, I agree with the intent, the point is that, as defined today, I think that there are the right constraints on the redefinition today to make sure this reconnection will make sense in all cases. Yves From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: mercredi 10 avril 2013 16:13 To: Delp, Christopher L (313K) Cc: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org); Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens Subject: Re: Inheriting Connectors I fully agree with Eran. We should look at the problem primarily from a user perspective. I've had over 20 years experience with this type of structure modeling and, based on that, users expect the inherited connector to be reconnected to the redefined part. If language is an issue, a tool can make it work that way. Bran On Wed, Apr 10, 2013 at 9:40 AM, Delp, Christopher L (313K) wrote: My $0.02 Connectors should be treated as parts as well. Unless they are redefined they should be inherited. <> Chris Delp Systems Architect NASA JPL On Apr 10, 2013, at 5:22 AM, "Nerijus Jankevicius" wrote: Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus 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=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=VkARJjL55YLwHc4DEdCbavAZdLgHinIvx3uYOaXmHhE=; b=pM8fogyOImbPGBgTu+0AV6ZMYfHA810RKU6Gb9XK6tAydOBYiNs2ZM8jpoTLC/sqMQ Huscftw2QeMXCigeW6B+V0Y3lrBfAsKUMLHR3aIXYvr/ZaZa39IyhFSRVyH0GpPYt3vY +GPjB+v1yocNZiicWtg8xcOva0m6hKrF93WgKwvOC4uh1UCI0WOVNZB+UAcqg25qTNa7 TfU1koiqISIUG6sUhFrw1Zj+xIjH0WDMzMnCPOCbFg+ycxmyoiz6ND+6Hi74nyc4dvD4 QKZ3liU0oDxiA6n2IEUOEFSQc6Sk+SG/aSh+rVohtfTG0aJctqmullV0n4+EpE2d451a dRQg== X-Received: by 10.220.248.200 with SMTP id mh8mr1704028vcb.51.1365605399203; Wed, 10 Apr 2013 07:49:59 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 10 Apr 2013 10:49:14 -0400 X-Google-Sender-Auth: ydm4XLkOD1auCUe4U1vraeEz44k Subject: Re: Inheriting Connectors To: Juergen Boldt Cc: Nerijus Jankevicius , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , Robert Karban , DELP , Tim Weilkiens X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Qr0deRps X-Brightmail-Tracker: AAAAAA== Hi Juergen, Yes, it is an issue. Bran On Wed, Apr 10, 2013 at 9:19 AM, Juergen Boldt wrote: issue? -Juergen At 08:22 AM 4/10/2013, Nerijus Jankevicius wrote: Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] From: Tim Weilkiens To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , "conrad.bock@nist.gov" CC: "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: Ac41+waYjLSIbY5NQ5aw9LcjpKtK+Q== Date: Wed, 10 Apr 2013 14:52:30 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR16Wag= X-Brightmail-Tracker: AAAAAA== Conrad, that is the same problem. We have two parts named a and connector ab is connected to the part a that is not available in the inherited context. Tim -----Original Message----- From: Bock, Conrad [conrad.bock@nist.gov] Received: Mittwoch, 10 Apr. 2013, 16:27 To: uml25-ftf@omg.org [uml25-ftf@omg.org]; sysml-rtf@omg.org [sysml-rtf@omg.org] CC: Robert.Karban@jpl.nasa.gov [Robert.Karban@jpl.nasa.gov]; Christopher.L.Delp@nasa.gov [Christopher.L.Delp@nasa.gov] Subject: RE: Inheriting Connectors Tim, et al, > I think that the connector ab is inherited. Unfortunately it is not connected > with a1, but with part of a that is not visible in the inherited context. > Connector ab is in an undefined state. That's an SysML or UML issue. What if the redefinition of property "a" in Context' was also named "a"? Conrad ----------------------------------------------------------------- oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Geschäsfü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 Der Inhalt dieser E-Mail ist nur fü Empfäer und nicht zur Veröntlichung oder unautorisierten Weitergabe bestimmt. X-Virus-Scanned: OK From: Ed Seidewitz To: "Juergen Boldt (juergen@omg.org)" CC: "Bran Selic (bran.selic@gmail.com)" , "uml25-ftf@omg.org" Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeZEo3vx/ZEABUWII2I9lAcq25jPxAiAgAAZIAD//8Rr8A== Date: Wed, 10 Apr 2013 16:17:38 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.48.209.197] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Qr0deRps X-Brightmail-Tracker: AAAAAA== Juergen . I am not seeing the messages I have sent to the UML 2.5 FTF list, so I am not sure that they are getting through. Did you see my earlier message that there are already existing issues on this? I don.t think we need another one. -- Ed From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Wednesday, April 10, 2013 10:49 AM To: Juergen Boldt Cc: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org); Robert Karban; DELP; Tim Weilkiens Subject: Re: Inheriting Connectors Hi Juergen, Yes, it is an issue. Bran On Wed, Apr 10, 2013 at 9:19 AM, Juergen Boldt wrote: issue? -Juergen At 08:22 AM 4/10/2013, Nerijus Jankevicius wrote: Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] From: Axel Scheithauer To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" CC: "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" , Tim Weilkiens , "conrad.bock@nist.gov" Subject: AW: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: Ac41+waYjLSIbY5NQ5aw9LcjpKtK+QAB+w/A Date: Wed, 10 Apr 2013 16:19:22 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.56] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR16Wag= X-Brightmail-Tracker: AAAAAA== Hi, I understand, that the repository would not contain a connector between b and a.. However that doesn.t mean that no link is implied for the instances being modeled. The repository also doesn.t contain a part b for Context., and yet it is implied to be present in instances of it. Therefore I think we need to look into the semantics of specialization. I believe it is not mentioned in the specification, but wouldn.t the Liskov Substitution Principle apply? The Context specifies, that b and a are connected. A specialization of this Block cannot separate them, without violating the Substitution Principle. A client of Context would expect them to be connected, even though one is redefined and now called a.. To give a real live example: Context could be a gearbox. b and a are gear-wheels. Now a is redefined to have let.s say another number of teeth. Still a user of the gearbox would expect, that turning wheel a (or redefined a.) will move wheel b. Therefore I think no change is necessary, except for maybe a clarification about inherited connectors (and, by the way, associations as well). Axel Von: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Gesendet: Mittwoch, 10. April 2013 16:53 An: uml25-ftf@omg.org; sysml-rtf@omg.org; conrad.bock@nist.gov Cc: Robert.Karban@jpl.nasa.gov; Christopher.L.Delp@nasa.gov Betreff: RE: Inheriting Connectors Conrad, that is the same problem. We have two parts named a and connector ab is connected to the part a that is not available in the inherited context. Tim -----Original Message----- From: Bock, Conrad [conrad.bock@nist.gov] Received: Mittwoch, 10 Apr. 2013, 16:27 To: uml25-ftf@omg.org [uml25-ftf@omg.org]; sysml-rtf@omg.org [sysml-rtf@omg.org] CC: Robert.Karban@jpl.nasa.gov [Robert.Karban@jpl.nasa.gov]; Christopher.L.Delp@nasa.gov [Christopher.L.Delp@nasa.gov] Subject: RE: Inheriting Connectors Tim, et al, > I think that the connector ab is inherited. Unfortunately it is not connected > with a1, but with part of a that is not visible in the inherited context. > Connector ab is in an undefined state. That's an SysML or UML issue. What if the redefinition of property "a" in Context' was also named "a"? Conrad ----------------------------------------------------------------- oose Innovative Informatik GmbH Kontorhaus Montblanc, Schulterblatt 36, D-20357 Hamburg HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Geschäsfü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 Der Inhalt dieser E-Mail ist nur fü Empfäer und nicht zur Veröntlichung oder unautorisierten Weitergabe bestimmt. From: "Bock, Conrad" To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" CC: "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" Date: Wed, 10 Apr 2013 12:34:00 -0400 Subject: RE: Inheriting Connectors, spec quote Thread-Topic: Inheriting Connectors, spec quote Thread-Index: Ac42CKqx5hW6/5ZaTPqlGP7SHWxfAA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3AGY7nJ016876 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Steve, > The connector ab is a feature of the class Context, and as such is > inherited in Context', independently of the redefinitions of the > Properties. But since a has been redefined in Context', it is not > inherited. So any attempt to use ab in Context' will lead to > something undesirable. This doesn't seem to be true, according to the Redefinition subclause in 9.2.3 (Semantics of Classifiers), see "when this occurs": Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member. The general (redefined) feature inherits in the sense that the special (redefining) feature stands in for it in all uses of the general feature. Conrad From: "Bock, Conrad" To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" CC: "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" Date: Wed, 10 Apr 2013 12:35:24 -0400 Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: Ac41+waYjLSIbY5NQ5aw9LcjpKtK+QACvTbQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3AGZWeA017072 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Tim, > that is the same problem. We have two parts named a and connector ab is > connected to the part a that is not available in the inherited > context. If that were true, it would be a much wider problem than connectors because so many elements refer to properties and are expected to work when inherited. For example, derived properties have OCL referring to properties, and behaviors refer to properties (as in Add Structural Feature Action or state machine transitions). Fortunately the spec doesn't have this problem, as far as I can tell. Conrad -----Original Message----- From: Bock, Conrad Sent: Wednesday, April 10, 2013 10:25 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org Cc: Robert.Karban@jpl.nasa.gov; Christopher.L.Delp@nasa.gov Subject: RE: Inheriting Connectors Tim, et al, > I think that the connector ab is inherited. Unfortunately it is not connected > with a1, but with part of a that is not visible in the inherited context. > Connector ab is in an undefined state. That's an SysML or UML issue. What if the redefinition of property "a" in Context' was also named "a"? Conrad From: "Bock, Conrad" To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" CC: Robert Karban , DELP Date: Wed, 10 Apr 2013 13:40:50 -0400 Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: Ac415l6fK+D8qlyaR8K7ylugM+8xyQAK+WMQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Nerijus, > If parts are redefined in a subclass, should connectors of original > redefined parts be inherited? Or lost/hidden/redefined too as > original part does not exist in a subclass anymore, so why connectors > should? According the spec (see quote I sent to Steve), the term "hidden" just means the special (redefining) property "a1" stands in for the general (redefined) property a, and all references the general property "a" inherited from the general classifier, like those from the general connector ends, resolve to the special property "a1" in the special classifier. IOW, I don't think there's a problem here, and as I said to Tim, if there were, it would be much wider than connectors. ConradFrom: Steve Cook To: "Bock, Conrad" , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" CC: "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" Subject: RE: Inheriting Connectors, spec quote Thread-Topic: Inheriting Connectors, spec quote Thread-Index: Ac42CKqx5hW6/5ZaTPqlGP7SHWxfAAACeFVw Date: Wed, 10 Apr 2013 17:43:04 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.103] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(189002)(199002)(76482001)(20776003)(47976001)(79102001)(51856001)(4396001)(53806001)(54356001)(81342001)(77982001)(73894001)(55846006)(81542001)(50466001)(23676001)(16406001)(59766001)(31966008)(74662001)(47446002)(69226001)(74502001)(80022001)(65816001)(54316002)(46102001)(47776003)(56816002)(33656001)(50986001)(56776001)(44976002)(63696002)(47736001)(621065001)(49866001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB037;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0812095267 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3AHhipY027706 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Conrad It doesn't inherit in the sense in which UML uses the word inherit. In UML, redefined members are excluded from the set of inherited members. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 10 April 2013 17:34 To: uml25-ftf@omg.org; sysml-rtf@omg.org Cc: Robert.Karban@jpl.nasa.gov; Christopher.L.Delp@nasa.gov Subject: RE: Inheriting Connectors, spec quote Steve, > The connector ab is a feature of the class Context, and as such is > inherited in Context', independently of the redefinitions of the > Properties. But since a has been redefined in Context', it is not > inherited. So any attempt to use ab in Context' will lead to > something undesirable. This doesn't seem to be true, according to the Redefinition subclause in 9.2.3 (Semantics of Classifiers), see "when this occurs": Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member. The general (redefined) feature inherits in the sense that the special (redefining) feature stands in for it in all uses of the general feature. Conrad From: "Bock, Conrad" To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" CC: "Robert.Karban@jpl.nasa.gov" , "Christopher.L.Delp@nasa.gov" Date: Wed, 10 Apr 2013 14:05:29 -0400 Subject: RE: Inheriting Connectors, spec quote Thread-Topic: Inheriting Connectors, spec quote Thread-Index: Ac42CKqx5hW6/5ZaTPqlGP7SHWxfAAACeFVwAAB9T2A= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3AI6rA4031397 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Steve, > It doesn't inherit in the sense in which UML uses the word inherit. In UML, > redefined members are excluded from the set of inherited members. Perhaps, but this doesn't affect the semantics of inherited connectors or any other inherited elements that refer to the general property. Those references "resolve" to the special (redefining) property, because the special property is taken "in place of" the the general one. I think the phrase "hidden by the redefinition" in the spec is confusing, because the spec changes the usual meaning of "hidden" to the definition after "in the sense that". The sentence would be clearer as: "When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), specifically, any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member." assuming inherited connectors and other elements referring to the redefined feature are considered to be "in the context of ... the specializing Classifier" due to inheritance. Conrad -----Original Message----- From: Bock, Conrad Sent: Wednesday, April 10, 2013 12:34 PM To: uml25-ftf@omg.org; sysml-rtf@omg.org Cc: Robert.Karban@jpl.nasa.gov; Christopher.L.Delp@nasa.gov Subject: RE: Inheriting Connectors, spec quote Steve, > The connector ab is a feature of the class Context, and as such is > inherited in Context', independently of the redefinitions of the > Properties. But since a has been redefined in Context', it is not > inherited. So any attempt to use ab in Context' will lead to > something undesirable. This doesn't seem to be true, according to the Redefinition subclause in 9.2.3 (Semantics of Classifiers), see "when this occurs": Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member. The general (redefined) feature inherits in the sense that the special (redefining) feature stands in for it in all uses of the general feature. Conrad From: "Rouquette, Nicolas F (313K)" To: "Bock, Conrad" , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" CC: "Karban, Robert (3101-Affiliate)" , "Christopher.L.Delp@nasa.gov" Subject: Re: Inheriting Connectors, spec quote Thread-Topic: Inheriting Connectors, spec quote Thread-Index: Ac42CKqx5hW6/5ZaTPqlGP7SHWxfAAACeFVwAAB9T2AAApEzAA== Date: Wed, 10 Apr 2013 19:08:27 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r3AJ8gAt008410 X-Brightmail-Tracker: AAAAAR16Wag= X-Brightmail-Tracker: AAAAAA== I agree with Conrad's interpretation; however, it is not compatible with UML 2.5 beta1. StructuredClassifier::/role is a derived union; it has only one subsetting property: StructuredClassifier::ownedAttribute That is, inherited ports/parts of a structured classifier are *NOT* roles of that structured classifier! This has a huge practical implication: There's no way to create a well-formed connector in UML 2.5 beta1 attached to inherited parts/ports; doing so would violate the connector's invariant in UML: roles The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier that owned the Connector, or they must be Ports of such roles. inv: structuredClassifier <> null and end->forAll( e | structuredClassifier.role->includes(e.role) or e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort)) - Nicolas. On 4/10/13 11:05 AM, "Bock, Conrad" wrote: >Steve, > > > It doesn't inherit in the sense in which UML uses the word inherit. >In UML, > > redefined members are excluded from the set of inherited members. > >Perhaps, but this doesn't affect the semantics of inherited connectors >or any other inherited elements that refer to the general property. >Those references "resolve" to the special (redefining) property, because >the special property is taken "in place of" the the general one. > >I think the phrase "hidden by the redefinition" in the spec is >confusing, because the spec changes the usual meaning of "hidden" to the >definition after "in the sense that". The sentence would be clearer as: > > "When this occurs, the redefining member contributes to the structure > or behavior of the specializing Classifier in place of the redefined > member(s), specifically, any reference to a redefined member in the > context of an instance of the specializing Classifier shall resolve to > the redefining member." > >assuming inherited connectors and other elements referring to the >redefined feature are considered to be "in the context of ... the >specializing Classifier" due to inheritance. > >Conrad > >-----Original Message----- >From: Bock, Conrad >Sent: Wednesday, April 10, 2013 12:34 PM >To: uml25-ftf@omg.org; sysml-rtf@omg.org >Cc: Robert.Karban@jpl.nasa.gov; Christopher.L.Delp@nasa.gov >Subject: RE: Inheriting Connectors, spec quote > >Steve, > > > The connector ab is a feature of the class Context, and as such is > > inherited in Context', independently of the redefinitions of the > > Properties. But since a has been redefined in Context', it is not > > inherited. So any attempt to use ab in Context' will lead to > > something undesirable. > >This doesn't seem to be true, according to the Redefinition subclause in >9.2.3 (Semantics of Classifiers), see "when this occurs": > > Redefinition is done in order to augment, constrain, or override the > redefined member(s) in the context of instances of the specializing > Classifier. When this occurs, the redefining member contributes to the > structure or behavior of the specializing Classifier in place of the > redefined member(s), which are hidden by the redefinition in the sense > that any reference to a redefined member in the context of an instance > of the specializing Classifier shall resolve to the redefining member. > >The general (redefined) feature inherits in the sense that the special >(redefining) feature stands in for it in all uses of the general >feature. > >Conrad m: "Rouquette, Nicolas F (313K)" To: "Bock, Conrad" , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" CC: "Karban, Robert (3101-Affiliate)" , "Christopher.L.Delp@nasa.gov" Subject: Re: Inheriting Connectors, spec quote Thread-Topic: Inheriting Connectors, spec quote Thread-Index: Ac42CKqx5hW6/5ZaTPqlGP7SHWxfAAACeFVwAAB9T2AAApEzAA== Date: Wed, 10 Apr 2013 19:08:27 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r3AJ8gAt008410 X-Brightmail-Tracker: AAAAAR16Wag= X-Brightmail-Tracker: AAAAAA== I agree with Conrad's interpretation; however, it is not compatible with UML 2.5 beta1. StructuredClassifier::/role is a derived union; it has only one subsetting property: StructuredClassifier::ownedAttribute That is, inherited ports/parts of a structured classifier are *NOT* roles of that structured classifier! This has a huge practical implication: There's no way to create a well-formed connector in UML 2.5 beta1 attached to inherited parts/ports; doing so would violate the connector's invariant in UML: roles The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier that owned the Connector, or they must be Ports of such roles. inv: structuredClassifier <> null and end->forAll( e | structuredClassifier.role->includes(e.role) or e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort)) - Nicolas. On 4/10/13 11:05 AM, "Bock, Conrad" wrote: >Steve, > > > It doesn't inherit in the sense in which UML uses the word inherit. >In UML, > > redefined members are excluded from the set of inherited members. > >Perhaps, but this doesn't affect the semantics of inherited connectors >or any other inherited elements that refer to the general property. >Those references "resolve" to the special (redefining) property, because >the special property is taken "in place of" the the general one. > >I think the phrase "hidden by the redefinition" in the spec is >confusing, because the spec changes the usual meaning of "hidden" to the >definition after "in the sense that". The sentence would be clearer as: > > "When this occurs, the redefining member contributes to the structure > or behavior of the specializing Classifier in place of the redefined > member(s), specifically, any reference to a redefined member in the > context of an instance of the specializing Classifier shall resolve to > the redefining member." > >assuming inherited connectors and other elements referring to the >redefined feature are considered to be "in the context of ... the >specializing Classifier" due to inheritance. > >Conrad > >-----Original Message----- >From: Bock, Conrad >Sent: Wednesday, April 10, 2013 12:34 PM >To: uml25-ftf@omg.org; sysml-rtf@omg.org >Cc: Robert.Karban@jpl.nasa.gov; Christopher.L.Delp@nasa.gov >Subject: RE: Inheriting Connectors, spec quote > >Steve, > > > The connector ab is a feature of the class Context, and as such is > > inherited in Context', independently of the redefinitions of the > > Properties. But since a has been redefined in Context', it is not > > inherited. So any attempt to use ab in Context' will lead to > > something undesirable. > >This doesn't seem to be true, according to the Redefinition subclause in >9.2.3 (Semantics of Classifiers), see "when this occurs": > > Redefinition is done in order to augment, constrain, or override the > redefined member(s) in the context of instances of the specializing > Classifier. When this occurs, the redefining member contributes to the > structure or behavior of the specializing Classifier in place of the > redefined member(s), which are hidden by the redefinition in the sense > that any reference to a redefined member in the context of an instance > of the specializing Classifier shall resolve to the redefining member. > >The general (redefined) feature inherits in the sense that the special >(redefining) feature stands in for it in all uses of the general >feature. > >Conrad >From: Ed Seidewitz To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" Date: Wed, 10 Apr 2013 15:25:37 -0400 Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeZEo3vx/ZEABUWII2I9lAcq25jPxAiA///AGjCAAFIBAA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0.81912 p=-0.985876 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-12301-c X-Mailprotector-ID: c3c251bb-6459-4afc-b00c-36f5e466befa X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAwr+n5EdeUK9HXkabA== X-Brightmail-Tracker: AAAAAA== OK, I am receiving messages from the UML 2.5 FTF list at eseidewitz@ivarjacobson.com, but it seems to only allow me to send messages to the list using ed-s@modeldriven.com! So I am going to resend a couple of messages I sent earlier today, starting with the one below. From: Ed Seidewitz Sent: Wednesday, April 10, 2013 10:34 AM To: 'Juergen Boldt'; Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: RE: Inheriting Connectors OK, everybody. As often happens, have had this discussion before, toward the end of last year. Please see Issues 18132 and 18171. I can also forward more of the old email thread. From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, April 10, 2013 9:19 AM To: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Re: Inheriting Connectors issue? -Juergen At 08:22 AM 4/10/2013, Nerijus Jankevicius wrote: Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] From: "Rouquette, Nicolas F (313K)" To: Ed Seidewitz , Ed Seidewitz , Nerijus Jankevicius CC: "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" Subject: Re: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeZLx4fPQcJJaUyOXZczWhZ2q5jQH18A//+66gA= Date: Wed, 10 Apr 2013 19:39:00 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAx15Qr0deRqaHXpZqA== X-Brightmail-Tracker: AAAAAA== Ed, Thanks for explaining, again, the subtle semantics of UML connectors. The problem, as I indicated on a different thread, is with the invariant: the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) Can you explain why do we have this invariant? From a practical standpoint, this invariant is counter-intuitive because it forces creating redefining inherited parts/ports in order to connect them in a specializing structured classifier. That is, a user must be cognizant of the classifier context in which a part/port is defined before attaching a connector to it. What justification is there for this cognitive burden on the user? From a semantic standpoint, since the semantics of a redefining part/port is to "replace" the redefined part/port inherited from a parent classifier, what does UML gain in requiring explicit redefinition of inherited parts/ports for connecting them? - Nicolas. From: Ed Seidewitz Date: Wednesday, April 10, 2013 9:46 AM To: Nerijus Jankevicius Cc: Robert Karban , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , JPL Subject: RE: Inheriting Connectors Nerijus . Nicolas asked almost exactly this same question back in September. This ultimately led to him submitting what became Issue 18132. Here is my analysis from then, which I believe still stands, with the model element names changed to reflect your example: In your example, block Context has three owned members: a, b and ab. These are all inheritable. Block Context. inherits b and ab, but it does not inherit a. Rather, it redefines a as a1. So, Context. also has three members: a1, b and ab, but it only owns a1. What, then, is the status of connector ab relative to block Context.? Since ab is inherited by Context., Context.::ab is just another name for Context::ab. Therefore, Context.::ab still connects Context::a and Context::b. Since ab is owned by Context and a and b are all owned attributes (and, hence, roles) of Context, the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) is not violated. (On the other hand, if Context. redefined ab, then the ends of the redefining connector would need, by this constraint, to be roles of Context. and could no longer be Context::a and Context::b . but could be redefinitions of them.) Now, Context. inherits b, but it no longer has a. So what are the semantics of Context.::ab when Context. is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of Context::a by Context.::a1). Under .Redefinition. in Subclause 9.2.3 of the UML 2.5 spec it says: .Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. It also notes later in the subclause that .The detailed semantics of redefinition vary for each specialization of RedefinableElement.. Unfortunately, no further details are given in the spec for redefinition of a Property, so the previously quoted paragraph is all we have to go on. The key point in this paragraph is that .any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. So, when we instantiate Context., we also get objects instantiated in Context.::a1 and Context::b and a link instantiated for ab. The link for ab connects the objects in Context::a and Context::b. However, in the context of Context., this .reference. to the .redefined member. Context::a .resolves. to the .redefining member. Context.::a1. That is, in the context of Context., the link instantiated for ab will connect the objects in Context.::a1 and Context.::b, even though the connector ab still has Context::a and Context::b on its ends. And this is type safe, since A. (the type of a1) is required to be a subtype of A (the type of a). The bottom line is that it is not the case that Context.::ab connects Context.::a1 and Context.::b syntactically in the model. Context.::ab is just Context::ab as inherited by Context., and this cannot change the syntactic structure of ab, which is to connect Context::a and Context::b. However, semantically it is the case that the link instantiated for ab in the context of an instance of Context. will connect the objects instantiated in Context.::a1 and Context.::b. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in the example (without the need to explicitly redefine ab)! -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 10, 2013 8:22 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus image001.png From: "Rouquette, Nicolas F (313K)" To: Ed Seidewitz , Ed Seidewitz , Nerijus Jankevicius CC: "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" Subject: Re: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeZLx4fPQcJJaUyOXZczWhZ2q5jQH18A//+66gCAAAb4AA== Date: Wed, 10 Apr 2013 20:03:56 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Qr0deRqa X-Brightmail-Tracker: AAAAAA== Actually, the problem is quite serious for SysML. Basically, any SysML Connector where a ConnectorEnd has the SysML NestedConnectorEnd stereotype applied violates the UML 2.5 beta1 Connector roles invariant. Why? Because SysML NestedConnectorEnd::/propertyPath : Property[1..*] means that the context of the connector is definitely not the same as the context of the connected end role precisely because it is defined in a different context (otherwise we wouldn't have a property path to reach that context) - Nicolas. From: , JPL Date: Wednesday, April 10, 2013 12:39 PM To: Ed Seidewitz , Ed Seidewitz , Nerijus Jankevicius Cc: Robert Karban , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" Subject: Re: Inheriting Connectors Ed, Thanks for explaining, again, the subtle semantics of UML connectors. The problem, as I indicated on a different thread, is with the invariant: the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) Can you explain why do we have this invariant? From a practical standpoint, this invariant is counter-intuitive because it forces creating redefining inherited parts/ports in order to connect them in a specializing structured classifier. That is, a user must be cognizant of the classifier context in which a part/port is defined before attaching a connector to it. What justification is there for this cognitive burden on the user? From a semantic standpoint, since the semantics of a redefining part/port is to "replace" the redefined part/port inherited from a parent classifier, what does UML gain in requiring explicit redefinition of inherited parts/ports for connecting them? - Nicolas. From: Ed Seidewitz Date: Wednesday, April 10, 2013 9:46 AM To: Nerijus Jankevicius Cc: Robert Karban , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , JPL Subject: RE: Inheriting Connectors Nerijus . Nicolas asked almost exactly this same question back in September. This ultimately led to him submitting what became Issue 18132. Here is my analysis from then, which I believe still stands, with the model element names changed to reflect your example: In your example, block Context has three owned members: a, b and ab. These are all inheritable. Block Context. inherits b and ab, but it does not inherit a. Rather, it redefines a as a1. So, Context. also has three members: a1, b and ab, but it only owns a1. What, then, is the status of connector ab relative to block Context.? Since ab is inherited by Context., Context.::ab is just another name for Context::ab. Therefore, Context.::ab still connects Context::a and Context::b. Since ab is owned by Context and a and b are all owned attributes (and, hence, roles) of Context, the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) is not violated. (On the other hand, if Context. redefined ab, then the ends of the redefining connector would need, by this constraint, to be roles of Context. and could no longer be Context::a and Context::b . but could be redefinitions of them.) Now, Context. inherits b, but it no longer has a. So what are the semantics of Context.::ab when Context. is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of Context::a by Context.::a1). Under .Redefinition. in Subclause 9.2.3 of the UML 2.5 spec it says: .Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. It also notes later in the subclause that .The detailed semantics of redefinition vary for each specialization of RedefinableElement.. Unfortunately, no further details are given in the spec for redefinition of a Property, so the previously quoted paragraph is all we have to go on. The key point in this paragraph is that .any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. So, when we instantiate Context., we also get objects instantiated in Context.::a1 and Context::b and a link instantiated for ab. The link for ab connects the objects in Context::a and Context::b. However, in the context of Context., this .reference. to the .redefined member. Context::a .resolves. to the .redefining member. Context.::a1. That is, in the context of Context., the link instantiated for ab will connect the objects in Context.::a1 and Context.::b, even though the connector ab still has Context::a and Context::b on its ends. And this is type safe, since A. (the type of a1) is required to be a subtype of A (the type of a). The bottom line is that it is not the case that Context.::ab connects Context.::a1 and Context.::b syntactically in the model. Context.::ab is just Context::ab as inherited by Context., and this cannot change the syntactic structure of ab, which is to connect Context::a and Context::b. However, semantically it is the case that the link instantiated for ab in the context of an instance of Context. will connect the objects instantiated in Context.::a1 and Context.::b. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in the example (without the need to explicitly redefine ab)! -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 10, 2013 8:22 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus image0011.png X-Virus-Scanned: OK From: Ed Seidewitz To: "Rouquette, Nicolas F (313K)" CC: "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeZLo3vx/ZEABUWII2I9lAcq25jQH18A//+66gCAAAb4AIAAAGKw Date: Wed, 10 Apr 2013 20:06:07 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [108.48.209.197] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAx15Qr0deRqaHXpZqA== X-Brightmail-Tracker: AAAAAA== Nicolas . You.re right, I think that is how the issue with this constraint originally came up. And it is probably a good reason for elevating the priority of its resolution in the FTF. -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, April 10, 2013 4:04 PM To: Ed Seidewitz; Ed Seidewitz; Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: Re: Inheriting Connectors Actually, the problem is quite serious for SysML. Basically, any SysML Connector where a ConnectorEnd has the SysML NestedConnectorEnd stereotype applied violates the UML 2.5 beta1 Connector roles invariant. Why? Because SysML NestedConnectorEnd::/propertyPath : Property[1..*] means that the context of the connector is definitely not the same as the context of the connected end role precisely because it is defined in a different context (otherwise we wouldn't have a property path to reach that context) - Nicolas. From: , JPL Date: Wednesday, April 10, 2013 12:39 PM To: Ed Seidewitz , Ed Seidewitz , Nerijus Jankevicius Cc: Robert Karban , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" Subject: Re: Inheriting Connectors Ed, Thanks for explaining, again, the subtle semantics of UML connectors. The problem, as I indicated on a different thread, is with the invariant: the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) Can you explain why do we have this invariant? From a practical standpoint, this invariant is counter-intuitive because it forces creating redefining inherited parts/ports in order to connect them in a specializing structured classifier. That is, a user must be cognizant of the classifier context in which a part/port is defined before attaching a connector to it. What justification is there for this cognitive burden on the user? From a semantic standpoint, since the semantics of a redefining part/port is to "replace" the redefined part/port inherited from a parent classifier, what does UML gain in requiring explicit redefinition of inherited parts/ports for connecting them? - Nicolas. From: Ed Seidewitz Date: Wednesday, April 10, 2013 9:46 AM To: Nerijus Jankevicius Cc: Robert Karban , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , JPL Subject: RE: Inheriting Connectors Nerijus . Nicolas asked almost exactly this same question back in September. This ultimately led to him submitting what became Issue 18132. Here is my analysis from then, which I believe still stands, with the model element names changed to reflect your example: In your example, block Context has three owned members: a, b and ab. These are all inheritable. Block Context. inherits b and ab, but it does not inherit a. Rather, it redefines a as a1. So, Context. also has three members: a1, b and ab, but it only owns a1. What, then, is the status of connector ab relative to block Context.? Since ab is inherited by Context., Context.::ab is just another name for Context::ab. Therefore, Context.::ab still connects Context::a and Context::b. Since ab is owned by Context and a and b are all owned attributes (and, hence, roles) of Context, the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) is not violated. (On the other hand, if Context. redefined ab, then the ends of the redefining connector would need, by this constraint, to be roles of Context. and could no longer be Context::a and Context::b . but could be redefinitions of them.) Now, Context. inherits b, but it no longer has a. So what are the semantics of Context.::ab when Context. is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of Context::a by Context.::a1). Under .Redefinition. in Subclause 9.2.3 of the UML 2.5 spec it says: .Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. It also notes later in the subclause that .The detailed semantics of redefinition vary for each specialization of RedefinableElement.. Unfortunately, no further details are given in the spec for redefinition of a Property, so the previously quoted paragraph is all we have to go on. The key point in this paragraph is that .any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. So, when we instantiate Context., we also get objects instantiated in Context.::a1 and Context::b and a link instantiated for ab. The link for ab connects the objects in Context::a and Context::b. However, in the context of Context., this .reference. to the .redefined member. Context::a .resolves. to the .redefining member. Context.::a1. That is, in the context of Context., the link instantiated for ab will connect the objects in Context.::a1 and Context.::b, even though the connector ab still has Context::a and Context::b on its ends. And this is type safe, since A. (the type of a1) is required to be a subtype of A (the type of a). The bottom line is that it is not the case that Context.::ab connects Context.::a1 and Context.::b syntactically in the model. Context.::ab is just Context::ab as inherited by Context., and this cannot change the syntactic structure of ab, which is to connect Context::a and Context::b. However, semantically it is the case that the link instantiated for ab in the context of an instance of Context. will connect the objects instantiated in Context.::a1 and Context.::b. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in the example (without the need to explicitly redefine ab)! -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 10, 2013 8:22 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus From: "BERNARD, Yves" To: Ed Seidewitz , "Rouquette, Nicolas F (313K)" , Nerijus Jankevicius CC: "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" Date: Thu, 11 Apr 2013 08:58:29 +0200 Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeZEo3vx/ZEABUWII2I9lAcq25jPo1bQgACKxwD//6zUIIAAu6sg 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 Ed, You wrote: .A. (the type of a1) is required to be a subtype of A (the type of a).. Even if it makes sense to me, I cannot find the constraint that implies the type of a redefining element to be a subtype of the redefined element in the UML 2.5 spec. Did I miss it? Yves From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: mercredi 10 avril 2013 21:56 To: Rouquette, Nicolas F (313K); Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: RE: Inheriting Connectors Nicolas . I don.t have any good explanation for this constraint. I am sure that it was intended to prevent malformed models in which connectors owned by one class connected parts of some other completely unrelated class. But my only guess as to why the constraint wasn.t loosened to allow connectors between inherited or redefined parts was that this may have been hard to specify when the metamodel was specified across multiple merge increments (with redefinition modeled in Classes::Kernel while connectors where in CompositeStructures::InternalStructures). With UML 2.5, this should no longer be a problem, so it is probably worth fixing the constraint. But you already have an issue in about this, and so it is up the UML 2.5 FTF to decide what to do about it this time around. Keep in mind, however, that, if connectors were allowed to have inherited parts at their ends, then such connectors would be in addition to any connectors already inherited, unless there was an explicit redefinition. For example, if, in Nerijus. example, a connector was allowed between Context.::a1 and (the inherited) Context.::b, then this would be in addition to the inherited connector ab, unless the new connector explicitly redefined ab. And, as my analysis showed, semantically there really isn.t any need to redefine the connector ab, since, in an instantiation of Context., the inherited ab already results in a link between the instances in Context.::a1 and Context::b, as one would intuitively expect. (Whether the graphical notation is confusing in representing this is another matter, though important in its own right.) -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, April 10, 2013 3:39 PM To: Ed Seidewitz; Ed Seidewitz; Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: Re: Inheriting Connectors Ed, Thanks for explaining, again, the subtle semantics of UML connectors. The problem, as I indicated on a different thread, is with the invariant: the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) Can you explain why do we have this invariant? From a practical standpoint, this invariant is counter-intuitive because it forces creating redefining inherited parts/ports in order to connect them in a specializing structured classifier. That is, a user must be cognizant of the classifier context in which a part/port is defined before attaching a connector to it. What justification is there for this cognitive burden on the user? From a semantic standpoint, since the semantics of a redefining part/port is to "replace" the redefined part/port inherited from a parent classifier, what does UML gain in requiring explicit redefinition of inherited parts/ports for connecting them? - Nicolas. From: Ed Seidewitz Date: Wednesday, April 10, 2013 9:46 AM To: Nerijus Jankevicius Cc: Robert Karban , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , JPL Subject: RE: Inheriting Connectors Nerijus . Nicolas asked almost exactly this same question back in September. This ultimately led to him submitting what became Issue 18132. Here is my analysis from then, which I believe still stands, with the model element names changed to reflect your example: In your example, block Context has three owned members: a, b and ab. These are all inheritable. Block Context. inherits b and ab, but it does not inherit a. Rather, it redefines a as a1. So, Context. also has three members: a1, b and ab, but it only owns a1. What, then, is the status of connector ab relative to block Context.? Since ab is inherited by Context., Context.::ab is just another name for Context::ab. Therefore, Context.::ab still connects Context::a and Context::b. Since ab is owned by Context and a and b are all owned attributes (and, hence, roles) of Context, the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) is not violated. (On the other hand, if Context. redefined ab, then the ends of the redefining connector would need, by this constraint, to be roles of Context. and could no longer be Context::a and Context::b . but could be redefinitions of them.) Now, Context. inherits b, but it no longer has a. So what are the semantics of Context.::ab when Context. is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of Context::a by Context.::a1). Under .Redefinition. in Subclause 9.2.3 of the UML 2.5 spec it says: .Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. It also notes later in the subclause that .The detailed semantics of redefinition vary for each specialization of RedefinableElement.. Unfortunately, no further details are given in the spec for redefinition of a Property, so the previously quoted paragraph is all we have to go on. The key point in this paragraph is that .any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. So, when we instantiate Context., we also get objects instantiated in Context.::a1 and Context::b and a link instantiated for ab. The link for ab connects the objects in Context::a and Context::b. However, in the context of Context., this .reference. to the .redefined member. Context::a .resolves. to the .redefining member. Context.::a1. That is, in the context of Context., the link instantiated for ab will connect the objects in Context.::a1 and Context.::b, even though the connector ab still has Context::a and Context::b on its ends. And this is type safe, since A. (the type of a1) is required to be a subtype of A (the type of a). The bottom line is that it is not the case that Context.::ab connects Context.::a1 and Context.::b syntactically in the model. Context.::ab is just Context::ab as inherited by Context., and this cannot change the syntactic structure of ab, which is to connect Context::a and Context::b. However, semantically it is the case that the link instantiated for ab in the context of an instance of Context. will connect the objects instantiated in Context.::a1 and Context.::b. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in the example (without the need to explicitly redefine ab)! -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 10, 2013 8:22 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus 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: Steve Cook To: "BERNARD, Yves" , Ed Seidewitz , "Rouquette, Nicolas F (313K)" , Nerijus Jankevicius CC: "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeZL1RDuh+9veE6Bgo6AnrLUuJjPo1bQgACKxwD//6zUIIAAu6sggAAOIAA= Date: Thu, 11 Apr 2013 07:44:45 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(52604002)(24454001)(365934001)(377454001)(164054002)(189002)(199002)(16236675001)(79102001)(81342001)(66926002)(46102001)(15202345001)(5343655001)(69226001)(47736001)(47446002)(31966008)(76482001)(33656001)(65816001)(50986001)(49866001)(5343635001)(564824004)(56776001)(47976001)(56816002)(77982001)(71186001)(18277545001)(74502001)(74662001)(4396001)(54356001)(51856001)(221733001)(67866001)(54316002)(512954001)(63696002)(81542001)(59766001)(55846006)(17760045001)(18094415001)(20776003)(80022001)(16406001)(53806001)(18276755001);DIR:OUT;SFP:;SCL:1;SRVR:BN1AFFO11HUB001;H:TK5EX14HUBC103.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0813C68E65 X-Virus-Scanned: amavisd-new at omg.org Yves The relevant constraint is encapsulated by the operation Property::isConsistentWith() -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 11 April 2013 07:58 To: Ed Seidewitz; Rouquette, Nicolas F (313K); Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: RE: Inheriting Connectors Ed, You wrote: .A. (the type of a1) is required to be a subtype of A (the type of a).. Even if it makes sense to me, I cannot find the constraint that implies the type of a redefining element to be a subtype of the redefined element in the UML 2.5 spec. Did I miss it? Yves From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: mercredi 10 avril 2013 21:56 To: Rouquette, Nicolas F (313K); Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: RE: Inheriting Connectors Nicolas . I don.t have any good explanation for this constraint. I am sure that it was intended to prevent malformed models in which connectors owned by one class connected parts of some other completely unrelated class. But my only guess as to why the constraint wasn.t loosened to allow connectors between inherited or redefined parts was that this may have been hard to specify when the metamodel was specified across multiple merge increments (with redefinition modeled in Classes::Kernel while connectors where in CompositeStructures::InternalStructures). With UML 2.5, this should no longer be a problem, so it is probably worth fixing the constraint. But you already have an issue in about this, and so it is up the UML 2.5 FTF to decide what to do about it this time around. Keep in mind, however, that, if connectors were allowed to have inherited parts at their ends, then such connectors would be in addition to any connectors already inherited, unless there was an explicit redefinition. For example, if, in Nerijus. example, a connector was allowed between Context.::a1 and (the inherited) Context.::b, then this would be in addition to the inherited connector ab, unless the new connector explicitly redefined ab. And, as my analysis showed, semantically there really isn.t any need to redefine the connector ab, since, in an instantiation of Context., the inherited ab already results in a link between the instances in Context.::a1 and Context::b, as one would intuitively expect. (Whether the graphical notation is confusing in representing this is another matter, though important in its own right.) -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, April 10, 2013 3:39 PM To: Ed Seidewitz; Ed Seidewitz; Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: Re: Inheriting Connectors Ed, Thanks for explaining, again, the subtle semantics of UML connectors. The problem, as I indicated on a different thread, is with the invariant: the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) Can you explain why do we have this invariant? From a practical standpoint, this invariant is counter-intuitive because it forces creating redefining inherited parts/ports in order to connect them in a specializing structured classifier. That is, a user must be cognizant of the classifier context in which a part/port is defined before attaching a connector to it. What justification is there for this cognitive burden on the user? From a semantic standpoint, since the semantics of a redefining part/port is to "replace" the redefined part/port inherited from a parent classifier, what does UML gain in requiring explicit redefinition of inherited parts/ports for connecting them? - Nicolas. From: Ed Seidewitz Date: Wednesday, April 10, 2013 9:46 AM To: Nerijus Jankevicius Cc: Robert Karban , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , JPL Subject: RE: Inheriting Connectors Nerijus . Nicolas asked almost exactly this same question back in September. This ultimately led to him submitting what became Issue 18132. Here is my analysis from then, which I believe still stands, with the model element names changed to reflect your example: In your example, block Context has three owned members: a, b and ab. These are all inheritable. Block Context. inherits b and ab, but it does not inherit a. Rather, it redefines a as a1. So, Context. also has three members: a1, b and ab, but it only owns a1. What, then, is the status of connector ab relative to block Context.? Since ab is inherited by Context., Context.::ab is just another name for Context::ab. Therefore, Context.::ab still connects Context::a and Context::b. Since ab is owned by Context and a and b are all owned attributes (and, hence, roles) of Context, the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) is not violated. (On the other hand, if Context. redefined ab, then the ends of the redefining connector would need, by this constraint, to be roles of Context. and could no longer be Context::a and Context::b . but could be redefinitions of them.) Now, Context. inherits b, but it no longer has a. So what are the semantics of Context.::ab when Context. is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of Context::a by Context.::a1). Under .Redefinition. in Subclause 9.2.3 of the UML 2.5 spec it says: .Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. It also notes later in the subclause that .The detailed semantics of redefinition vary for each specialization of RedefinableElement.. Unfortunately, no further details are given in the spec for redefinition of a Property, so the previously quoted paragraph is all we have to go on. The key point in this paragraph is that .any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. So, when we instantiate Context., we also get objects instantiated in Context.::a1 and Context::b and a link instantiated for ab. The link for ab connects the objects in Context::a and Context::b. However, in the context of Context., this .reference. to the .redefined member. Context::a .resolves. to the .redefining member. Context.::a1. That is, in the context of Context., the link instantiated for ab will connect the objects in Context.::a1 and Context.::b, even though the connector ab still has Context::a and Context::b on its ends. And this is type safe, since A. (the type of a1) is required to be a subtype of A (the type of a). The bottom line is that it is not the case that Context.::ab connects Context.::a1 and Context.::b syntactically in the model. Context.::ab is just Context::ab as inherited by Context., and this cannot change the syntactic structure of ab, which is to connect Context::a and Context::b. However, semantically it is the case that the link instantiated for ab in the context of an instance of Context. will connect the objects instantiated in Context.::a1 and Context.::b. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in the example (without the need to explicitly redefine ab)! -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 10, 2013 8:22 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus 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: Inheriting Connectors From: Nerijus Jankevicius Date: Thu, 11 Apr 2013 11:17:14 +0300 Cc: Robert Karban , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "Rouquette, Nicolas F (313K) (nicolas.f.rouquette@jpl.nasa.gov)" To: Ed Seidewitz X-Mailer: Apple Mail (2.1085) X-Virus-Scanned: amavisd-new at omg.org Ed, That's fine, clear and intuitive (with exception of stupid ownership constraint which is removed in SysML). Our execution tool does exactly the same. But it does not answer the main question - how these connectors could be represented in specialized classifier composite structure diagram? Is it legal to show them attached to redefining part symbol? This is what people want. Nerijus On Apr 10, 2013, at 7:46 PM, Ed Seidewitz wrote: Nerijus . Nicolas asked almost exactly this same question back in September. This ultimately led to him submitting what became Issue 18132. Here is my analysis from then, which I believe still stands, with the model element names changed to reflect your example: In your example, block Context has three owned members: a, b and ab. These are all inheritable. Block Context. inherits b and ab, but it does not inherit a. Rather, it redefines a as a1. So, Context. also has three members: a1, b and ab, but it only owns a1. What, then, is the status of connector ab relative to block Context.? Since ab is inherited by Context., Context.::ab is just another name for Context::ab. Therefore, Context.::ab still connects Context::a and Context::b. Since ab is owned by Context and a and b are all owned attributes (and, hence, roles) of Context, the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) is not violated. (On the other hand, if Context. redefined ab, then the ends of the redefining connector would need, by this constraint, to be roles of Context. and could no longer be Context::a and Context::b . but could be redefinitions of them.) Now, Context. inherits b, but it no longer has a. So what are the semantics of Context.::ab when Context. is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of Context::a by Context.::a1). Under .Redefinition. in Subclause 9.2.3 of the UML 2.5 spec it says: .Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. It also notes later in the subclause that .The detailed semantics of redefinition vary for each specialization of RedefinableElement.. Unfortunately, no further details are given in the spec for redefinition of a Property, so the previously quoted paragraph is all we have to go on. The key point in this paragraph is that .any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. So, when we instantiate Context., we also get objects instantiated in Context.::a1 and Context::b and a link instantiated for ab. The link for ab connects the objects in Context::a and Context::b. However, in the context of Context., this .reference. to the .redefined member. Context::a .resolves. to the .redefining member. Context.::a1. That is, in the context of Context., the link instantiated for ab will connect the objects in Context.::a1 and Context.::b, even though the connector ab still has Context::a and Context::b on its ends. And this is type safe, since A. (the type of a1) is required to be a subtype of A (the type of a). The bottom line is that it is not the case that Context.::ab connects Context.::a1 and Context.::b syntactically in the model. Context.::ab is just Context::ab as inherited by Context., and this cannot change the syntactic structure of ab, which is to connect Context::a and Context::b. However, semantically it is the case that the link instantiated for ab in the context of an instance of Context. will connect the objects instantiated in Context.::a1 and Context.::b. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in the example (without the need to explicitly redefine ab)! -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 10, 2013 8:22 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus From: Steve Cook To: Nerijus Jankevicius , Ed Seidewitz CC: Robert Karban , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "Rouquette, Nicolas F (313K) (nicolas.f.rouquette@jpl.nasa.gov)" Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeaT1RDuh+9veE6Bgo6AnrLUuJjQrwJigAAEmQA= Date: Thu, 11 Apr 2013 08:46:47 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(24454001)(377454001)(199002)(164054002)(189002)(56776001)(81342001)(81542001)(54316002)(76482001)(51856001)(53806001)(20776003)(44976002)(71186001)(16236675001)(74502001)(564824004)(65816001)(31966008)(33656001)(5343655001)(47446002)(221733001)(18277545001)(46102001)(54356001)(512954001)(69226001)(59766001)(16406001)(55846006)(47736001)(80022001)(5343635001)(77982001)(56816002)(74662001)(47976001)(49866001)(18276755001)(63696002)(79102001)(4396001)(15202345001)(50986001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB031;H:TK5EX14HUBC107.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0813C68E65 X-Virus-Scanned: amavisd-new at omg.org A difficulties with Ed.s excellent explanation is that it all rests on the meaning of the words .any reference.. Unfortunately these words, in the overall background of UML semantics, are poorly defined. Somewhere on this thread, Conrad proposed the following examples: >OCL referring to properties, and behaviors refer to properties (as in Add Structural Feature Action or state machine transitions) As for OCL, I would expect the semantics for this situation to be in the OCL 2.3.1 spec. They are . and seem to be inconsistent and contradictory. For the definition of oclAsType(), it says this: .In the case of feature definition, casting an object to a supertype of its actual type does not access the supertype.s definition of the feature; according to the semantics of redefinition, the redefined feature simply does not exist for the object.. However, 7.6.8 says .Whenever properties are redefined within a type, the property of the supertypes can be accessed using the oclAsType() operation.. As for Add Structural Feature Action, I would expect some words in the semantics of Structural Feature Actions to clarify what feature is actually affected in the case of redefinition. I cannot find any such words. I would also expect something in LinkActions to handle the case of connectors with/without a type. There isn.t anything. If I try to summarize the situation: - The semantics embodied in Ed.s explanation are intuitively desirable - It is also desirable to relax the connector roles invariant - People think this is high priority for UML 2.5 To fix this we need to improve explanations of property and connector redefinition; we need to enhance the semantics of Link Actions and Structural Feature Actions to take account of feature redefinition and connectors; we need to relax the connector roles constraint to permit connectors between inherited roles; we need to specify notations to handle the various flavours of connector inheritance and redefinition; and OCL needs to fix its contradiction. Do I have this correct? -- Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 11 April 2013 09:17 To: Ed Seidewitz Cc: Robert Karban; DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org); Rouquette, Nicolas F (313K) (nicolas.f.rouquette@jpl.nasa.gov) Subject: Re: Inheriting Connectors Ed, That's fine, clear and intuitive (with exception of stupid ownership constraint which is removed in SysML). Our execution tool does exactly the same. But it does not answer the main question - how these connectors could be represented in specialized classifier composite structure diagram? Is it legal to show them attached to redefining part symbol? This is what people want. Nerijus On Apr 10, 2013, at 7:46 PM, Ed Seidewitz wrote: Nerijus . Nicolas asked almost exactly this same question back in September. This ultimately led to him submitting what became Issue 18132. Here is my analysis from then, which I believe still stands, with the model element names changed to reflect your example: In your example, block Context has three owned members: a, b and ab. These are all inheritable. Block Context. inherits b and ab, but it does not inherit a. Rather, it redefines a as a1. So, Context. also has three members: a1, b and ab, but it only owns a1. What, then, is the status of connector ab relative to block Context.? Since ab is inherited by Context., Context.::ab is just another name for Context::ab. Therefore, Context.::ab still connects Context::a and Context::b. Since ab is owned by Context and a and b are all owned attributes (and, hence, roles) of Context, the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) is not violated. (On the other hand, if Context. redefined ab, then the ends of the redefining connector would need, by this constraint, to be roles of Context. and could no longer be Context::a and Context::b . but could be redefinitions of them.) Now, Context. inherits b, but it no longer has a. So what are the semantics of Context.::ab when Context. is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of Context::a by Context.::a1). Under .Redefinition. in Subclause 9.2.3 of the UML 2.5 spec it says: .Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. It also notes later in the subclause that .The detailed semantics of redefinition vary for each specialization of RedefinableElement.. Unfortunately, no further details are given in the spec for redefinition of a Property, so the previously quoted paragraph is all we have to go on. The key point in this paragraph is that .any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. So, when we instantiate Context., we also get objects instantiated in Context.::a1 and Context::b and a link instantiated for ab. The link for ab connects the objects in Context::a and Context::b. However, in the context of Context., this .reference. to the .redefined member. Context::a .resolves. to the .redefining member. Context.::a1. That is, in the context of Context., the link instantiated for ab will connect the objects in Context.::a1 and Context.::b, even though the connector ab still has Context::a and Context::b on its ends. And this is type safe, since A. (the type of a1) is required to be a subtype of A (the type of a). The bottom line is that it is not the case that Context.::ab connects Context.::a1 and Context.::b syntactically in the model. Context.::ab is just Context::ab as inherited by Context., and this cannot change the syntactic structure of ab, which is to connect Context::a and Context::b. However, semantically it is the case that the link instantiated for ab in the context of an instance of Context. will connect the objects instantiated in Context.::a1 and Context.::b. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in the example (without the need to explicitly redefine ab)! -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 10, 2013 8:22 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus From: Steve Cook To: Ed Seidewitz , "Rouquette, Nicolas F (313K)" , Nerijus Jankevicius CC: "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeZL1RDuh+9veE6Bgo6AnrLUuJjQH18A//+66gCAAAS/gIAA2JJw Date: Thu, 11 Apr 2013 08:52:55 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(52604002)(164054002)(199002)(189002)(377454001)(47976001)(56816002)(79102001)(74502001)(20776003)(221733001)(81542001)(66926002)(47446002)(33656001)(67866001)(18277545001)(4396001)(51856001)(18276755001)(55846006)(54356001)(80022001)(74662001)(54316002)(71186001)(44976002)(69226001)(15202345001)(56776001)(77982001)(81342001)(5343655001)(46102001)(31966008)(17760045001)(59766001)(65816001)(49866001)(50986001)(16406001)(63696002)(512954001)(564824004)(47736001)(16796002)(16236675001)(53806001)(76482001)(18094415001)(5343635001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB009;H:TK5EX14HUBC103.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0813C68E65 X-Virus-Scanned: amavisd-new at omg.org Regarding the last two paragraphs of Ed.s note, does SysML have a need to distinguish the cases where a connector is (a) inherited, (b) redefined, and (c) inherited and another connector defined between the same two roles? -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 10 April 2013 20:56 To: Rouquette, Nicolas F (313K); Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: RE: Inheriting Connectors Nicolas . I don.t have any good explanation for this constraint. I am sure that it was intended to prevent malformed models in which connectors owned by one class connected parts of some other completely unrelated class. But my only guess as to why the constraint wasn.t loosened to allow connectors between inherited or redefined parts was that this may have been hard to specify when the metamodel was specified across multiple merge increments (with redefinition modeled in Classes::Kernel while connectors where in CompositeStructures::InternalStructures). With UML 2.5, this should no longer be a problem, so it is probably worth fixing the constraint. But you already have an issue in about this, and so it is up the UML 2.5 FTF to decide what to do about it this time around. Keep in mind, however, that, if connectors were allowed to have inherited parts at their ends, then such connectors would be in addition to any connectors already inherited, unless there was an explicit redefinition. For example, if, in Nerijus. example, a connector was allowed between Context.::a1 and (the inherited) Context.::b, then this would be in addition to the inherited connector ab, unless the new connector explicitly redefined ab. And, as my analysis showed, semantically there really isn.t any need to redefine the connector ab, since, in an instantiation of Context., the inherited ab already results in a link between the instances in Context.::a1 and Context::b, as one would intuitively expect. (Whether the graphical notation is confusing in representing this is another matter, though important in its own right.) -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, April 10, 2013 3:39 PM To: Ed Seidewitz; Ed Seidewitz; Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: Re: Inheriting Connectors Ed, Thanks for explaining, again, the subtle semantics of UML connectors. The problem, as I indicated on a different thread, is with the invariant: the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) Can you explain why do we have this invariant? From a practical standpoint, this invariant is counter-intuitive because it forces creating redefining inherited parts/ports in order to connect them in a specializing structured classifier. That is, a user must be cognizant of the classifier context in which a part/port is defined before attaching a connector to it. What justification is there for this cognitive burden on the user? From a semantic standpoint, since the semantics of a redefining part/port is to "replace" the redefined part/port inherited from a parent classifier, what does UML gain in requiring explicit redefinition of inherited parts/ports for connecting them? - Nicolas. From: Ed Seidewitz Date: Wednesday, April 10, 2013 9:46 AM To: Nerijus Jankevicius Cc: Robert Karban , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org" , JPL Subject: RE: Inheriting Connectors Nerijus . Nicolas asked almost exactly this same question back in September. This ultimately led to him submitting what became Issue 18132. Here is my analysis from then, which I believe still stands, with the model element names changed to reflect your example: In your example, block Context has three owned members: a, b and ab. These are all inheritable. Block Context. inherits b and ab, but it does not inherit a. Rather, it redefines a as a1. So, Context. also has three members: a1, b and ab, but it only owns a1. What, then, is the status of connector ab relative to block Context.? Since ab is inherited by Context., Context.::ab is just another name for Context::ab. Therefore, Context.::ab still connects Context::a and Context::b. Since ab is owned by Context and a and b are all owned attributes (and, hence, roles) of Context, the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) is not violated. (On the other hand, if Context. redefined ab, then the ends of the redefining connector would need, by this constraint, to be roles of Context. and could no longer be Context::a and Context::b . but could be redefinitions of them.) Now, Context. inherits b, but it no longer has a. So what are the semantics of Context.::ab when Context. is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of Context::a by Context.::a1). Under .Redefinition. in Subclause 9.2.3 of the UML 2.5 spec it says: .Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. It also notes later in the subclause that .The detailed semantics of redefinition vary for each specialization of RedefinableElement.. Unfortunately, no further details are given in the spec for redefinition of a Property, so the previously quoted paragraph is all we have to go on. The key point in this paragraph is that .any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. So, when we instantiate Context., we also get objects instantiated in Context.::a1 and Context::b and a link instantiated for ab. The link for ab connects the objects in Context::a and Context::b. However, in the context of Context., this .reference. to the .redefined member. Context::a .resolves. to the .redefining member. Context.::a1. That is, in the context of Context., the link instantiated for ab will connect the objects in Context.::a1 and Context.::b, even though the connector ab still has Context::a and Context::b on its ends. And this is type safe, since A. (the type of a1) is required to be a subtype of A (the type of a). The bottom line is that it is not the case that Context.::ab connects Context.::a1 and Context.::b syntactically in the model. Context.::ab is just Context::ab as inherited by Context., and this cannot change the syntactic structure of ab, which is to connect Context::a and Context::b. However, semantically it is the case that the link instantiated for ab in the context of an instance of Context. will connect the objects instantiated in Context.::a1 and Context.::b. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in the example (without the need to explicitly redefine ab)! -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 10, 2013 8:22 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus Subject: RE: Inheriting Connectors X-KeepSent: FEC84603:A89D057F-C2257B4A:00336F98; type=4; name=$KeepSent To: Steve Cook Cc: DELP , Ed Seidewitz , Nerijus Jankevicius , "Rouquette, Nicolas F (313K)" , "Karban, Robert (3101-Affiliate)" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , Tim Weilkiens , "uml25-ftf@omg.org" X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Eran Gery Date: Thu, 11 Apr 2013 12:33:47 +0300 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.3FP2 ZX853FP2HF3|December 12, 2012) at 11/04/2013 12:33:38 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13041109-1948-0000-0000-000004CBBDB5 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3B9XxFC005821 Content-Transfer-Encoding: 8bit Steve - Steve, Did you mean to distinguish from a notation standpoint? As for case (c), I do not see the practicality for doing it in SysML, although technically possible. One case which is useful is to add a connector to another port, but I do not think it falls in category (C). But in any case, in that case I expect to see two connectors, hence you will distinguish. Between (a) and (b) I do see value to notationally show that the connector has been redefined. Best regards, Eran Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Steve Cook To: Ed Seidewitz , "Rouquette, Nicolas F (313K)" , Nerijus Jankevicius , Cc: "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" Date: 11/04/2013 11:54 AM Subject: RE: Inheriting Connectors Regarding the last two paragraphs of Ed.s note, does SysML have a need to distinguish the cases where a connector is (a) inherited, (b) redefined, and (c) inherited and another connector defined between the same two roles? -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 10 April 2013 20:56 To: Rouquette, Nicolas F (313K); Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: RE: Inheriting Connectors Nicolas ­ I don.t have any good explanation for this constraint. I am sure that it was intended to prevent malformed models in which connectors owned by one class connected parts of some other completely unrelated class. But my only guess as to why the constraint wasn.t loosened to allow connectors between inherited or redefined parts was that this may have been hard to specify when the metamodel was specified across multiple merge increments (with redefinition modeled in Classes::Kernel while connectors where in CompositeStructures::InternalStructures). With UML 2.5, this should no longer be a problem, so it is probably worth fixing the constraint. But you already have an issue in about this, and so it is up the UML 2.5 FTF to decide what to do about it this time around. Keep in mind, however, that, if connectors were allowed to have inherited parts at their ends, then such connectors would be in addition to any connectors already inherited, unless there was an explicit redefinition. For example, if, in Nerijus. example, a connector was allowed between Context.::a1 and (the inherited) Context.::b, then this would be in addition to the inherited connector ab, unless the new connector explicitly redefined ab. And, as my analysis showed, semantically there really isn.t any need to redefine the connector ab, since, in an instantiation of Context., the inherited ab already results in a link between the instances in Context.::a1 and Context::b, as one would intuitively expect. (Whether the graphical notation is confusing in representing this is another matter, though important in its own right.) -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, April 10, 2013 3:39 PM To: Ed Seidewitz; Ed Seidewitz; Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org ; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: Re: Inheriting Connectors Ed, Thanks for explaining, again, the subtle semantics of UML connectors. The problem, as I indicated on a different thread, is with the invariant: the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) Can you explain why do we have this invariant? >From a practical standpoint, this invariant is counter-intuitive because it forces creating redefining inherited parts/ports in order to connect them in a specializing structured classifier. That is, a user must be cognizant of the classifier context in which a part/port is defined before attaching a connector to it. What justification is there for this cognitive burden on the user? >From a semantic standpoint, since the semantics of a redefining part/port is to "replace" the redefined part/port inherited from a parent classifier, what does UML gain in requiring explicit redefinition of inherited parts/ports for connecting them? - Nicolas. From: Ed Seidewitz Date: Wednesday, April 10, 2013 9:46 AM To: Nerijus Jankevicius Cc: Robert Karban , DELP < Christopher.L.Delp@nasa.gov>, Tim Weilkiens , " uml25-ftf@omg.org" , "sysml-rtf@omg.org" < sysml-rtf@omg.org>, JPL Subject: RE: Inheriting Connectors Nerijus ­ Nicolas asked almost exactly this same question back in September. This ultimately led to him submitting what became Issue 18132. Here is my analysis from then, which I believe still stands, with the model element names changed to reflect your example: In your example, block Context has three owned members: a, b and ab. These are all inheritable. Block Context. inherits b and ab, but it does not inherit a. Rather, it redefines a as a1. So, Context. also has three members: a1, b and ab, but it only owns a1. What, then, is the status of connector ab relative to block Context.? Since ab is inherited by Context., Context.::ab is just another name for Context::ab. Therefore, Context.::ab still connects Context::a and Context::b. Since ab is owned by Context and a and b are all owned attributes (and, hence, roles) of Context, the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) is not violated. (On the other hand, if Context. redefined ab, then the ends of the redefining connector would need, by this constraint, to be roles of Context. and could no longer be Context::a and Context::b ­ but could be redefinitions of them.) Now, Context. inherits b, but it no longer has a. So what are the semantics of Context.::ab when Context. is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of Context::a by Context.::a1). Under .Redefinition. in Subclause 9.2.3 of the UML 2.5 spec it says: .Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. It also notes later in the subclause that .The detailed semantics of redefinition vary for each specialization of RedefinableElement.. Unfortunately, no further details are given in the spec for redefinition of a Property, so the previously quoted paragraph is all we have to go on. The key point in this paragraph is that .any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. So, when we instantiate Context., we also get objects instantiated in Context.::a1 and Context::b and a link instantiated for ab. The link for ab connects the objects in Context::a and Context::b. However, in the context of Context., this .reference. to the .redefined member. Context::a .resolves. to the .redefining member. Context.::a1. That is, in the context of Context., the link instantiated for ab will connect the objects in Context.::a1 and Context.::b, even though the connector ab still has Context::a and Context::b on its ends. And this is type safe, since A. (the type of a1) is required to be a subtype of A (the type of a). The bottom line is that it is not the case that Context.::ab connects Context.::a1 and Context.::b syntactically in the model. Context.::ab is just Context::ab as inherited by Context., and this cannot change the syntactic structure of ab, which is to connect Context::a and Context::b. However, semantically it is the case that the link instantiated for ab in the context of an instance of Context. will connect the objects instantiated in Context.::a1 and Context.::b. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in the example (without the need to explicitly redefine ab)! -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 10, 2013 8:22 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus Subject: RE: Inheriting Connectors X-KeepSent: FEC84603:A89D057F-C2257B4A:00336F98; type=4; name=$KeepSent To: Steve Cook Cc: DELP , Ed Seidewitz , Nerijus Jankevicius , "Rouquette, Nicolas F (313K)" , "Karban, Robert (3101-Affiliate)" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , Tim Weilkiens , "uml25-ftf@omg.org" X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Eran Gery Date: Thu, 11 Apr 2013 12:33:47 +0300 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.3FP2 ZX853FP2HF3|December 12, 2012) at 11/04/2013 12:33:38 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13041109-1948-0000-0000-000004CBBDB5 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3B9Xx5j005819 Content-Transfer-Encoding: 8bit Steve - Steve, Did you mean to distinguish from a notation standpoint? As for case (c), I do not see the practicality for doing it in SysML, although technically possible. One case which is useful is to add a connector to another port, but I do not think it falls in category (C). But in any case, in that case I expect to see two connectors, hence you will distinguish. Between (a) and (b) I do see value to notationally show that the connector has been redefined. Best regards, Eran Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Steve Cook To: Ed Seidewitz , "Rouquette, Nicolas F (313K)" , Nerijus Jankevicius , Cc: "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" Date: 11/04/2013 11:54 AM Subject: RE: Inheriting Connectors Regarding the last two paragraphs of Ed.s note, does SysML have a need to distinguish the cases where a connector is (a) inherited, (b) redefined, and (c) inherited and another connector defined between the same two roles? -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 10 April 2013 20:56 To: Rouquette, Nicolas F (313K); Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: RE: Inheriting Connectors Nicolas ­ I don.t have any good explanation for this constraint. I am sure that it was intended to prevent malformed models in which connectors owned by one class connected parts of some other completely unrelated class. But my only guess as to why the constraint wasn.t loosened to allow connectors between inherited or redefined parts was that this may have been hard to specify when the metamodel was specified across multiple merge increments (with redefinition modeled in Classes::Kernel while connectors where in CompositeStructures::InternalStructures). With UML 2.5, this should no longer be a problem, so it is probably worth fixing the constraint. But you already have an issue in about this, and so it is up the UML 2.5 FTF to decide what to do about it this time around. Keep in mind, however, that, if connectors were allowed to have inherited parts at their ends, then such connectors would be in addition to any connectors already inherited, unless there was an explicit redefinition. For example, if, in Nerijus. example, a connector was allowed between Context.::a1 and (the inherited) Context.::b, then this would be in addition to the inherited connector ab, unless the new connector explicitly redefined ab. And, as my analysis showed, semantically there really isn.t any need to redefine the connector ab, since, in an instantiation of Context., the inherited ab already results in a link between the instances in Context.::a1 and Context::b, as one would intuitively expect. (Whether the graphical notation is confusing in representing this is another matter, though important in its own right.) -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, April 10, 2013 3:39 PM To: Ed Seidewitz; Ed Seidewitz; Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org ; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: Re: Inheriting Connectors Ed, Thanks for explaining, again, the subtle semantics of UML connectors. The problem, as I indicated on a different thread, is with the invariant: the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) Can you explain why do we have this invariant? >From a practical standpoint, this invariant is counter-intuitive because it forces creating redefining inherited parts/ports in order to connect them in a specializing structured classifier. That is, a user must be cognizant of the classifier context in which a part/port is defined before attaching a connector to it. What justification is there for this cognitive burden on the user? >From a semantic standpoint, since the semantics of a redefining part/port is to "replace" the redefined part/port inherited from a parent classifier, what does UML gain in requiring explicit redefinition of inherited parts/ports for connecting them? - Nicolas. From: Ed Seidewitz Date: Wednesday, April 10, 2013 9:46 AM To: Nerijus Jankevicius Cc: Robert Karban , DELP < Christopher.L.Delp@nasa.gov>, Tim Weilkiens , " uml25-ftf@omg.org" , "sysml-rtf@omg.org" < sysml-rtf@omg.org>, JPL Subject: RE: Inheriting Connectors Nerijus ­ Nicolas asked almost exactly this same question back in September. This ultimately led to him submitting what became Issue 18132. Here is my analysis from then, which I believe still stands, with the model element names changed to reflect your example: In your example, block Context has three owned members: a, b and ab. These are all inheritable. Block Context. inherits b and ab, but it does not inherit a. Rather, it redefines a as a1. So, Context. also has three members: a1, b and ab, but it only owns a1. What, then, is the status of connector ab relative to block Context.? Since ab is inherited by Context., Context.::ab is just another name for Context::ab. Therefore, Context.::ab still connects Context::a and Context::b. Since ab is owned by Context and a and b are all owned attributes (and, hence, roles) of Context, the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) is not violated. (On the other hand, if Context. redefined ab, then the ends of the redefining connector would need, by this constraint, to be roles of Context. and could no longer be Context::a and Context::b ­ but could be redefinitions of them.) Now, Context. inherits b, but it no longer has a. So what are the semantics of Context.::ab when Context. is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of Context::a by Context.::a1). Under .Redefinition. in Subclause 9.2.3 of the UML 2.5 spec it says: .Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. It also notes later in the subclause that .The detailed semantics of redefinition vary for each specialization of RedefinableElement.. Unfortunately, no further details are given in the spec for redefinition of a Property, so the previously quoted paragraph is all we have to go on. The key point in this paragraph is that .any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. So, when we instantiate Context., we also get objects instantiated in Context.::a1 and Context::b and a link instantiated for ab. The link for ab connects the objects in Context::a and Context::b. However, in the context of Context., this .reference. to the .redefined member. Context::a .resolves. to the .redefining member. Context.::a1. That is, in the context of Context., the link instantiated for ab will connect the objects in Context.::a1 and Context.::b, even though the connector ab still has Context::a and Context::b on its ends. And this is type safe, since A. (the type of a1) is required to be a subtype of A (the type of a). The bottom line is that it is not the case that Context.::ab connects Context.::a1 and Context.::b syntactically in the model. Context.::ab is just Context::ab as inherited by Context., and this cannot change the syntactic structure of ab, which is to connect Context::a and Context::b. However, semantically it is the case that the link instantiated for ab in the context of an instance of Context. will connect the objects instantiated in Context.::a1 and Context.::b. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in the example (without the need to explicitly redefine ab)! -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 10, 2013 8:22 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus From: Steve Cook To: Eran Gery CC: DELP , Ed Seidewitz , Nerijus Jankevicius , "Rouquette, Nicolas F (313K)" , "Karban, Robert (3101-Affiliate)" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , Tim Weilkiens , "uml25-ftf@omg.org" Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeZL1RDuh+9veE6Bgo6AnrLUuJjQH18A//+66gCAAAS/gIAA2JJwgAAL7oCAAAQSUA== Date: Thu, 11 Apr 2013 10:06:16 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(189002)(199002)(50466001)(47976001)(55846006)(16406001)(65816001)(31966008)(621065001)(56776001)(74502001)(49866001)(47736001)(79102001)(44976002)(73894001)(221733001)(47446002)(4396001)(80022001)(16796002)(33656001)(23676001)(81342001)(77982001)(47776003)(76482001)(20776003)(51856001)(50986001)(53806001)(63696002)(74662001)(69226001)(59766001)(46102001)(54316002)(54356001)(56816002)(81542001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB017;H:TK5EX14MLTC104.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0813C68E65 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3BA8nDt003123 Content-Transfer-Encoding: 8bit Eran I was actually asking about semantic differences, although if these options are all possible the notation should clearly distinguish between them. >From a UML perspective I can see the following possible semantic differences: - the redefined connector might be typed by a different association (potentially even an association class) - "the redefining Connector may have a type that specializes the type of the redefined Connector". - the redefined connector might have different "contracts" -- Steve -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: 11 April 2013 10:34 To: Steve Cook Cc: DELP; Ed Seidewitz; Nerijus Jankevicius; Rouquette, Nicolas F (313K); Karban, Robert (3101-Affiliate); sysml-rtf@omg.org (sysml-rtf@omg.org); Tim Weilkiens; uml25-ftf@omg.org Subject: RE: Inheriting Connectors Steve - Steve, Did you mean to distinguish from a notation standpoint? As for case (c), I do not see the practicality for doing it in SysML, although technically possible. One case which is useful is to add a connector to another port, but I do not think it falls in category (C). But in any case, in that case I expect to see two connectors, hence you will distinguish. Between (a) and (b) I do see value to notationally show that the connector has been redefined. Best regards, Eran Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Steve Cook To: Ed Seidewitz , "Rouquette, Nicolas F (313K)" , Nerijus Jankevicius , Cc: "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" Date: 11/04/2013 11:54 AM Subject: RE: Inheriting Connectors Regarding the last two paragraphs of Ed.s note, does SysML have a need to distinguish the cases where a connector is (a) inherited, (b) redefined, and (c) inherited and another connector defined between the same two roles? -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 10 April 2013 20:56 To: Rouquette, Nicolas F (313K); Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: RE: Inheriting Connectors Nicolas ­ I don.t have any good explanation for this constraint. I am sure that it was intended to prevent malformed models in which connectors owned by one class connected parts of some other completely unrelated class. But my only guess as to why the constraint wasn.t loosened to allow connectors between inherited or redefined parts was that this may have been hard to specify when the metamodel was specified across multiple merge increments (with redefinition modeled in Classes::Kernel while connectors where in CompositeStructures::InternalStructures). With UML 2.5, this should no longer be a problem, so it is probably worth fixing the constraint. But you already have an issue in about this, and so it is up the UML 2.5 FTF to decide what to do about it this time around. Keep in mind, however, that, if connectors were allowed to have inherited parts at their ends, then such connectors would be in addition to any connectors already inherited, unless there was an explicit redefinition. For example, if, in Nerijus. example, a connector was allowed between Context.::a1 and (the inherited) Context.::b, then this would be in addition to the inherited connector ab, unless the new connector explicitly redefined ab. And, as my analysis showed, semantically there really isn.t any need to redefine the connector ab, since, in an instantiation of Context., the inherited ab already results in a link between the instances in Context.::a1 and Context::b, as one would intuitively expect. (Whether the graphical notation is confusing in representing this is another matter, though important in its own right.) -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, April 10, 2013 3:39 PM To: Ed Seidewitz; Ed Seidewitz; Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org ; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: Re: Inheriting Connectors Ed, Thanks for explaining, again, the subtle semantics of UML connectors. The problem, as I indicated on a different thread, is with the invariant: the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) Can you explain why do we have this invariant? >From a practical standpoint, this invariant is counter-intuitive because it forces creating redefining inherited parts/ports in order to connect them in a specializing structured classifier. That is, a user must be cognizant of the classifier context in which a part/port is defined before attaching a connector to it. What justification is there for this cognitive burden on the user? >From a semantic standpoint, since the semantics of a redefining part/port is to "replace" the redefined part/port inherited from a parent classifier, what does UML gain in requiring explicit redefinition of inherited parts/ports for connecting them? - Nicolas. From: Ed Seidewitz Date: Wednesday, April 10, 2013 9:46 AM To: Nerijus Jankevicius Cc: Robert Karban , DELP < Christopher.L.Delp@nasa.gov>, Tim Weilkiens , " uml25-ftf@omg.org" , "sysml-rtf@omg.org" < sysml-rtf@omg.org>, JPL Subject: RE: Inheriting Connectors Nerijus ­ Nicolas asked almost exactly this same question back in September. This ultimately led to him submitting what became Issue 18132. Here is my analysis from then, which I believe still stands, with the model element names changed to reflect your example: In your example, block Context has three owned members: a, b and ab. These are all inheritable. Block Context. inherits b and ab, but it does not inherit a. Rather, it redefines a as a1. So, Context. also has three members: a1, b and ab, but it only owns a1. What, then, is the status of connector ab relative to block Context.? Since ab is inherited by Context., Context.::ab is just another name for Context::ab. Therefore, Context.::ab still connects Context::a and Context::b. Since ab is owned by Context and a and b are all owned attributes (and, hence, roles) of Context, the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) is not violated. (On the other hand, if Context. redefined ab, then the ends of the redefining connector would need, by this constraint, to be roles of Context. and could no longer be Context::a and Context::b ­ but could be redefinitions of them.) Now, Context. inherits b, but it no longer has a. So what are the semantics of Context.::ab when Context. is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of Context::a by Context.::a1). Under .Redefinition. in Subclause 9.2.3 of the UML 2.5 spec it says: .Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. It also notes later in the subclause that .The detailed semantics of redefinition vary for each specialization of RedefinableElement.. Unfortunately, no further details are given in the spec for redefinition of a Property, so the previously quoted paragraph is all we have to go on. The key point in this paragraph is that .any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. So, when we instantiate Context., we also get objects instantiated in Context.::a1 and Context::b and a link instantiated for ab. The link for ab connects the objects in Context::a and Context::b. However, in the context of Context., this .reference. to the .redefined member. Context::a .resolves. to the .redefining member. Context.::a1. That is, in the context of Context., the link instantiated for ab will connect the objects in Context.::a1 and Context.::b, even though the connector ab still has Context::a and Context::b on its ends. And this is type safe, since A. (the type of a1) is required to be a subtype of A (the type of a). The bottom line is that it is not the case that Context.::ab connects Context.::a1 and Context.::b syntactically in the model. Context.::ab is just Context::ab as inherited by Context., and this cannot change the syntactic structure of ab, which is to connect Context::a and Context::b. However, semantically it is the case that the link instantiated for ab in the context of an instance of Context. will connect the objects instantiated in Context.::a1 and Context.::b. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in the example (without the need to explicitly redefine ab)! -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 10, 2013 8:22 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus Subject: RE: Inheriting Connectors X-KeepSent: BB73E003:ECC55D7E-C2257B4A:003A4CC4; type=4; name=$KeepSent To: Steve Cook Cc: DELP , Ed Seidewitz , Nerijus Jankevicius , "Rouquette, Nicolas F (313K)" , "Karban, Robert (3101-Affiliate)" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , Tim Weilkiens , "uml25-ftf@omg.org" X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Eran Gery Date: Thu, 11 Apr 2013 13:58:54 +0300 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.3FP2 ZX853FP2HF3|December 12, 2012) at 11/04/2013 13:58:44 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13041110-5024-0000-0000-000005B73C4A X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3BAx86H008946 Content-Transfer-Encoding: 8bit Steve - thanks, understand now... I can only contribute that in general connector typing is something which is very hard for general SysML users to understand. Connectors are used as bindings across ports of parts, and tools need to "infer" the type in most of the cases for most users to actually use them. There are cases where connector types are used to specify "pin mappings" (something Conrad introduced it I believe) , in which case you may need to use different association classes for the redefined connector. This is a very advanced use case but it does exist, and it relates to your first use case. Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Steve Cook To: Eran Gery/Haifa/IBM@IBMIL, Cc: DELP , Ed Seidewitz , Nerijus Jankevicius , "Rouquette, Nicolas F (313K)" , "Karban, Robert (3101-Affiliate)" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , Tim Weilkiens , "uml25-ftf@omg.org" Date: 11/04/2013 01:08 PM Subject: RE: Inheriting Connectors Eran I was actually asking about semantic differences, although if these options are all possible the notation should clearly distinguish between them. >From a UML perspective I can see the following possible semantic differences: - the redefined connector might be typed by a different association (potentially even an association class) - "the redefining Connector may have a type that specializes the type of the redefined Connector". - the redefined connector might have different "contracts" -- Steve -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: 11 April 2013 10:34 To: Steve Cook Cc: DELP; Ed Seidewitz; Nerijus Jankevicius; Rouquette, Nicolas F (313K); Karban, Robert (3101-Affiliate); sysml-rtf@omg.org (sysml-rtf@omg.org); Tim Weilkiens; uml25-ftf@omg.org Subject: RE: Inheriting Connectors Steve - Steve, Did you mean to distinguish from a notation standpoint? As for case (c), I do not see the practicality for doing it in SysML, although technically possible. One case which is useful is to add a connector to another port, but I do not think it falls in category (C). But in any case, in that case I expect to see two connectors, hence you will distinguish. Between (a) and (b) I do see value to notationally show that the connector has been redefined. Best regards, Eran Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Steve Cook To: Ed Seidewitz , "Rouquette, Nicolas F (313K)" , Nerijus Jankevicius , Cc: "Karban, Robert (3101-Affiliate)" , DELP , Tim Weilkiens , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" Date: 11/04/2013 11:54 AM Subject: RE: Inheriting Connectors Regarding the last two paragraphs of Ed.s note, does SysML have a need to distinguish the cases where a connector is (a) inherited, (b) redefined, and (c) inherited and another connector defined between the same two roles? -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 10 April 2013 20:56 To: Rouquette, Nicolas F (313K); Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: RE: Inheriting Connectors Nicolas ­ I don.t have any good explanation for this constraint. I am sure that it was intended to prevent malformed models in which connectors owned by one class connected parts of some other completely unrelated class. But my only guess as to why the constraint wasn.t loosened to allow connectors between inherited or redefined parts was that this may have been hard to specify when the metamodel was specified across multiple merge increments (with redefinition modeled in Classes::Kernel while connectors where in CompositeStructures::InternalStructures). With UML 2.5, this should no longer be a problem, so it is probably worth fixing the constraint. But you already have an issue in about this, and so it is up the UML 2.5 FTF to decide what to do about it this time around. Keep in mind, however, that, if connectors were allowed to have inherited parts at their ends, then such connectors would be in addition to any connectors already inherited, unless there was an explicit redefinition. For example, if, in Nerijus. example, a connector was allowed between Context.::a1 and (the inherited) Context.::b, then this would be in addition to the inherited connector ab, unless the new connector explicitly redefined ab. And, as my analysis showed, semantically there really isn.t any need to redefine the connector ab, since, in an instantiation of Context., the inherited ab already results in a link between the instances in Context.::a1 and Context::b, as one would intuitively expect. (Whether the graphical notation is confusing in representing this is another matter, though important in its own right.) -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, April 10, 2013 3:39 PM To: Ed Seidewitz; Ed Seidewitz; Nerijus Jankevicius Cc: Karban, Robert (3101-Affiliate); DELP; Tim Weilkiens; uml25-ftf@omg.org ; sysml-rtf@omg.org (sysml-rtf@omg.org) Subject: Re: Inheriting Connectors Ed, Thanks for explaining, again, the subtle semantics of UML connectors. The problem, as I indicated on a different thread, is with the invariant: the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) Can you explain why do we have this invariant? >From a practical standpoint, this invariant is counter-intuitive because it forces creating redefining inherited parts/ports in order to connect them in a specializing structured classifier. That is, a user must be cognizant of the classifier context in which a part/port is defined before attaching a connector to it. What justification is there for this cognitive burden on the user? >From a semantic standpoint, since the semantics of a redefining part/port is to "replace" the redefined part/port inherited from a parent classifier, what does UML gain in requiring explicit redefinition of inherited parts/ports for connecting them? - Nicolas. From: Ed Seidewitz Date: Wednesday, April 10, 2013 9:46 AM To: Nerijus Jankevicius Cc: Robert Karban , DELP < Christopher.L.Delp@nasa.gov>, Tim Weilkiens , " uml25-ftf@omg.org" , "sysml-rtf@omg.org" < sysml-rtf@omg.org>, JPL Subject: RE: Inheriting Connectors Nerijus ­ Nicolas asked almost exactly this same question back in September. This ultimately led to him submitting what became Issue 18132. Here is my analysis from then, which I believe still stands, with the model element names changed to reflect your example: In your example, block Context has three owned members: a, b and ab. These are all inheritable. Block Context. inherits b and ab, but it does not inherit a. Rather, it redefines a as a1. So, Context. also has three members: a1, b and ab, but it only owns a1. What, then, is the status of connector ab relative to block Context.? Since ab is inherited by Context., Context.::ab is just another name for Context::ab. Therefore, Context.::ab still connects Context::a and Context::b. Since ab is owned by Context and a and b are all owned attributes (and, hence, roles) of Context, the Connector::roles constraint (which requires a connector to have roles with the same owner as the connector) is not violated. (On the other hand, if Context. redefined ab, then the ends of the redefining connector would need, by this constraint, to be roles of Context. and could no longer be Context::a and Context::b ­ but could be redefinitions of them.) Now, Context. inherits b, but it no longer has a. So what are the semantics of Context.::ab when Context. is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of Context::a by Context.::a1). Under .Redefinition. in Subclause 9.2.3 of the UML 2.5 spec it says: .Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. It also notes later in the subclause that .The detailed semantics of redefinition vary for each specialization of RedefinableElement.. Unfortunately, no further details are given in the spec for redefinition of a Property, so the previously quoted paragraph is all we have to go on. The key point in this paragraph is that .any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member.. So, when we instantiate Context., we also get objects instantiated in Context.::a1 and Context::b and a link instantiated for ab. The link for ab connects the objects in Context::a and Context::b. However, in the context of Context., this .reference. to the .redefined member. Context::a .resolves. to the .redefining member. Context.::a1. That is, in the context of Context., the link instantiated for ab will connect the objects in Context.::a1 and Context.::b, even though the connector ab still has Context::a and Context::b on its ends. And this is type safe, since A. (the type of a1) is required to be a subtype of A (the type of a). The bottom line is that it is not the case that Context.::ab connects Context.::a1 and Context.::b syntactically in the model. Context.::ab is just Context::ab as inherited by Context., and this cannot change the syntactic structure of ab, which is to connect Context::a and Context::b. However, semantically it is the case that the link instantiated for ab in the context of an instance of Context. will connect the objects instantiated in Context.::a1 and Context.::b. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in the example (without the need to explicitly redefine ab)! -- Ed From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, April 10, 2013 8:22 AM To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP; Tim Weilkiens Subject: Inheriting Connectors Experts, If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should? If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model. See diagram below. Thanks, Nerijus From: "Bock, Conrad" To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" CC: Robert Karban , DELP Date: Thu, 11 Apr 2013 08:25:15 -0400 Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeaT1RDuh+9veE6Bgo6AnrLUuJjQrwJigAAEmQCAADtl8A== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Steve, > As for Add Structural Feature Action, I would expect some words in the > semantics of Structural Feature Actions to clarify what feature is actually > affected in the case of redefinition. I wouldn't expect such words. The text in the Redefinition subclause I cited clearly says uses of the general (redefined) feature in instances the specialized (redefining) class are to be treated as if they are uses of the special (redefining) property. For Add Structural Feature Action this means adding a value to the general (redefined) property in instances of the special (redefining) class adds values to the special (redefining) property of that instance. There are so many places in the UML that reference redefinable elements you would have an enormous task to find them all and modify them for the general statement given in the Redefinition subclause. And there is no need to do so, the general statement is clear enough. > A difficulties with Ed's excellent explanation is that it all rests > on the meaning of the words "any reference". Unfortunately these > words, in the overall background of UML semantics, are poorly > defined. I think these terms are well-enough understood in the community to interpret elements referring to redefined features. The one I gave above for Add Structural Feature Action is straightforward. Conrad -----Original Message----- From: Bock, Conrad Sent: Wednesday, April 10, 2013 12:34 PM To: uml25-ftf@omg.org; sysml-rtf@omg.org Cc: Robert.Karban@jpl.nasa.gov; Christopher.L.Delp@nasa.gov Subject: RE: Inheriting Connectors, spec quote Steve, > The connector ab is a feature of the class Context, and as such is > inherited in Context', independently of the redefinitions of the > Properties. But since a has been redefined in Context', it is not > inherited. So any attempt to use ab in Context' will lead to > something undesirable. This doesn't seem to be true, according to the Redefinition subclause in 9.2.3 (Semantics of Classifiers), see "when this occurs": Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member. The general (redefined) feature inherits in the sense that the special (redefining) feature stands in for it in all uses of the general feature. Conrad From: "Bock, Conrad" To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" CC: Robert Karban , DELP Date: Thu, 11 Apr 2013 08:27:48 -0400 Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: Ac42jTmNPsm3eUsISpm3OX7ge6FAOwAIbSaA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== Nerijus, > But it does not answer the main question - how these connectors could > be represented in specialized classifier composite structure diagram? > Is it legal to show them attached to redefining part symbol? This question applies much more generally, even beyond redefinition. First, how are inherited element shown at all? Second, how are they shown when they refer to redefined elements? Conrad X-Trusted-NM: yes Subject: Re: Inheriting Connectors From: Nerijus Jankevicius Date: Thu, 11 Apr 2013 16:15:59 +0300 Cc: "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , Robert Karban , DELP To: "Bock, Conrad" X-Mailer: Apple Mail (2.1085) X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r3BDGBVZ026136 X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== Conrad, Sure. We have the first problem on being unable to show inherited attributes on Class in Class diagrams (BDDs) ( but naturally show them as regular parts in composite structure diagrams as everyone expect that). Nerijus On Apr 11, 2013, at 3:27 PM, Bock, Conrad wrote: > Nerijus, > >> But it does not answer the main question - how these connectors could >> be represented in specialized classifier composite structure diagram? >> Is it legal to show them attached to redefining part symbol? > > This question applies much more generally, even beyond redefinition. > First, how are inherited element shown at all? Second, how are they > shown when they refer to redefined elements? > > Conrad From: Steve Cook To: "Bock, Conrad" , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" CC: Robert Karban , DELP Subject: RE: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeaT1RDuh+9veE6Bgo6AnrLUuJjQrwJigAAEmQCAADtl8IAAH3SQ Date: Thu, 11 Apr 2013 14:27:54 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(199002)(189002)(13464002)(377454001)(16406001)(54316002)(23726001)(69226001)(74502001)(56816002)(50466001)(47446002)(49866001)(65816001)(80022001)(44976002)(81542001)(5343655001)(76482001)(47776003)(47736001)(46102001)(79102001)(50986001)(33656001)(53806001)(59766001)(56776001)(46406002)(63696002)(20776003)(54356001)(81342001)(55846006)(74662001)(221733001)(77982001)(51856001)(4396001)(31966008)(47976001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB023;H:TK5EX14HUBC105.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0813C68E65 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r3BETUSU004205 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Conrad I'll agree with you, as long as the subject paragraph is improved to clarify what "any reference" means - you already proposed some new wording. Note that if "any reference" were to include the reference from the redefining element to the redefined element, then the redefining element must be interpreted as redefining itself, which is clearly absurd. I'll also observe that the analogous problem to the one we are discussing occurs with redefined ActivityNodes and ActivityEdges, and also States and Transitions. For the latter, the following notation is specified: "Inherited elements in a StateMachine, Region, or State are drawn either with dashed lines or light-toned lines (e.g., Figure 14.37)" The trouble with extending this notation to roles is that dashed-line boxes are already specified to signify non-composite roles. We have an interesting discussion to look forward to at our next UML 2.5 FTF telecom, I think. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 11 April 2013 13:25 To: uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Robert Karban; DELP Subject: RE: Inheriting Connectors Steve, > As for Add Structural Feature Action, I would expect some words in the > semantics of Structural Feature Actions to clarify what feature is actually > affected in the case of redefinition. I wouldn't expect such words. The text in the Redefinition subclause I cited clearly says uses of the general (redefined) feature in instances the specialized (redefining) class are to be treated as if they are uses of the special (redefining) property. For Add Structural Feature Action this means adding a value to the general (redefined) property in instances of the special (redefining) class adds values to the special (redefining) property of that instance. There are so many places in the UML that reference redefinable elements you would have an enormous task to find them all and modify them for the general statement given in the Redefinition subclause. And there is no need to do so, the general statement is clear enough. > A difficulties with Ed's excellent explanation is that it all rests > on the meaning of the words "any reference". Unfortunately these > words, in the overall background of UML semantics, are poorly > defined. I think these terms are well-enough understood in the community to interpret elements referring to redefined features. The one I gave above for Add Structural Feature Action is straightforward. Conrad -----Original Message----- From: Bock, Conrad Sent: Wednesday, April 10, 2013 12:34 PM To: uml25-ftf@omg.org; sysml-rtf@omg.org Cc: Robert.Karban@jpl.nasa.gov; Christopher.L.Delp@nasa.gov Subject: RE: Inheriting Connectors, spec quote Steve, > The connector ab is a feature of the class Context, and as such is > inherited in Context', independently of the redefinitions of the > Properties. But since a has been redefined in Context', it is not > inherited. So any attempt to use ab in Context' will lead to > something undesirable. This doesn't seem to be true, according to the Redefinition subclause in 9.2.3 (Semantics of Classifiers), see "when this occurs": Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier. When this occurs, the redefining member contributes to the structure or behavior of the specializing Classifier in place of the redefined member(s), which are hidden by the redefinition in the sense that any reference to a redefined member in the context of an instance of the specializing Classifier shall resolve to the redefining member. The general (redefined) feature inherits in the sense that the special (redefining) feature stands in for it in all uses of the general feature. Conrad From: "Rouquette, Nicolas F (313K)" To: "Bock, Conrad" , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" CC: "Karban, Robert (3101-Affiliate)" , DELP Subject: Re: Inheriting Connectors Thread-Topic: Inheriting Connectors Thread-Index: AQHONeZLx4fPQcJJaUyOXZczWhZ2q5jQH18AgAEEHwCAAAhBgIAAPQqA//+x0AA= Date: Thu, 11 Apr 2013 14:45:27 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r3BEl7BQ006640 X-Brightmail-Tracker: AAAAAR16Wag= X-Brightmail-Tracker: AAAAAA== Conrad, On 4/11/13 5:25 AM, "Bock, Conrad" wrote: >Steve, > > > As for Add Structural Feature Action, I would expect some words in the > > semantics of Structural Feature Actions to clarify what feature is >actually > > affected in the case of redefinition. > >I wouldn't expect such words. I would because it's currently unclear. >The text in the Redefinition subclause I >cited clearly says uses of the general (redefined) feature in instances >the specialized (redefining) class are to be treated as if they are uses >of the special (redefining) property. The ambiguity is what "treated as if.." really means (see below). >For Add Structural Feature Action >this means adding a value to the general (redefined) property in >instances of the special (redefining) class adds values to the special >(redefining) property of that instance. You're interpreting "treaded as if" in the spec to mean "adds values to the redefining properties". There are corner cases where it is necessary to clarify what "adds values to the redefining properties" actually means. 1) the redefining property has 0..0 multiplicity It's OK to add a value to the redefined property but this should have no effect on the redefining property since it can't have any value! 2) the redefining property is typed by a specialization of the type of the redefined property If the value is not an instance of the redefining property type, it cannot be added to the redefining property. 3) same as (2) except that there are multiple redefining properties for the same redefined property What happens if the types of the redefining properties are disjoint and/or overlapping? Is the value added to each redefining property whose type classifies the value and whose multiplicity allows doing so? - Nicolas. > >Conrad > > >-----Original Message----- >From: Bock, Conrad >Sent: Wednesday, April 10, 2013 12:34 PM >To: uml25-ftf@omg.org; sysml-rtf@omg.org >Cc: Robert.Karban@jpl.nasa.gov; Christopher.L.Delp@nasa.gov >Subject: RE: Inheriting Connectors, spec quote > >Steve, > > > The connector ab is a feature of the class Context, and as such is > > inherited in Context', independently of the redefinitions of the > > Properties. But since a has been redefined in Context', it is not > > inherited. So any attempt to use ab in Context' will lead to > > something undesirable. > >This doesn't seem to be true, according to the Redefinition subclause in >9.2.3 (Semantics of Classifiers), see "when this occurs": > > Redefinition is done in order to augment, constrain, or override the > redefined member(s) in the context of instances of the specializing > Classifier. When this occurs, the redefining member contributes to the > structure or behavior of the specializing Classifier in place of the > redefined member(s), which are hidden by the redefinition in the sense > that any reference to a redefined member in the context of an instance > of the specializing Classifier shall resolve to the redefining member. > >The general (redefined) feature inherits in the sense that the special >(redefining) feature stands in for it in all uses of the general >feature. > >Conrad DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=GWhhCj1H9WaOo9NOtyXyPAvPKpGJZ4JPrzuSwTeAN6Q=; b=k7M2WPPFQa10rKmggB0wEHXR9sqHO9Bjbx0SdJvLiAuwE/wrh/m9aMLPUQ+TyLCHgO GWIUyyh46K5laOOOMMMFUfxKopbgOSUlkFGWPZeOoJsfd56/NOLhummu3OWWNJAAPfOg +JSSNnT2NT3f6rM6o+JDp08lTJBQDb5qExQszSHn84Va55Mt/FyE5njYdxHCkzlywWcS 4gyE6ekyjbw57q4Uec/s4nWGhgqkXmBWE/4yHFJYOHK66gZpk/Byz5sEoksbdulCMQje h0tM4fQSMrMKs+vIPnunog4wanzu1B3fmqTfE9N8d9q83DMXIfjLsh678ED5j1pyE68E n/mw== X-Received: by 10.52.70.108 with SMTP id l12mr4592739vdu.40.1365693783974; Thu, 11 Apr 2013 08:23:03 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 11 Apr 2013 11:22:23 -0400 X-Google-Sender-Auth: eokCmdpo4GtOn-Rovaubz_4i1E8 Subject: Re: Inheriting Connectors To: Nerijus Jankevicius Cc: "Bock, Conrad" , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , Robert Karban , DELP X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== RSA-RTE from IBM uses a grey pen to show inherited parts and connectors. Users seem to like it. Bran On Thu, Apr 11, 2013 at 9:15 AM, Nerijus Jankevicius wrote: Conrad, Sure. We have the first problem on being unable to show inherited attributes on Class in Class diagrams (BDDs) ( but naturally show them as regular parts in composite structure diagrams as everyone expect that). Nerijus On Apr 11, 2013, at 3:27 PM, Bock, Conrad wrote: > Nerijus, > >> But it does not answer the main question - how these connectors could >> be represented in specialized classifier composite structure diagram? >> Is it legal to show them attached to redefining part symbol? > > This question applies much more generally, even beyond redefinition. > First, how are inherited element shown at all? Second, how are they > shown when they refer to redefined elements? > > Conrad From: "Bock, Conrad" To: "uml25-ftf@omg.org" Date: Fri, 17 May 2013 08:35:10 -0400 Subject: RE: Notation for inherited, gray, UML DI, 18650 Thread-Topic: Notation for inherited, gray, UML DI, 18650 Thread-Index: Ac5S+t2izLYBID7GRaGGiz8tuVSceQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r4HCZFrt005005 X-Brightmail-Tracker: AAAAAR3FFAo= X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit P.S. Also looks like UML DI will need to extended for all redefinable elements to enable interchange to tell whether the option to show inherited elements in lighter colors was used or not by the sender. Conrad Steve, Just remembered that UML DI has a property to tell whether inherited states should be shown in dashed, gray, or not different from others (these are the options currently given by state machine notation), see inheritedStateBorder on UMLStateDiagram in Figure B.13 (Behavior Diagrams). I assume this should be updated for the resolution of 18684. I need to go now, but will check back in the morning if you need me to provide the changes. Conrad From: Steve Cook To: "Bock, Conrad" , "uml25-ftf@omg.org" Subject: RE: Notation for inherited, gray, UML DI, 18650 Thread-Topic: Notation for inherited, gray, UML DI, 18650 Thread-Index: Ac5S+t2izLYBID7GRaGGiz8tuVSceQAALXfQ Date: Fri, 17 May 2013 12:41:54 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(13464003)(199002)(31014003)(189002)(50466002)(44976003)(46102001)(77982001)(76482001)(54356001)(23676002)(65816001)(74366001)(79102001)(59766001)(51856001)(49866001)(20776003)(55846006)(54316002)(16406001)(69226001)(81542001)(33656001)(56776001)(81342001)(56816002)(6806003)(47776003)(74706001)(80022001)(47446002)(47736001)(74502001)(53806001)(63696002)(47976001)(50986001)(31966008)(74876001)(74662001)(4396001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB004;H:TK5EX14HUBC106.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08497C3D99 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r4HCgNrt005739 X-Brightmail-Tracker: AAAAAR3FFAo= X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Conrad I think you are right. Probably easiest to raise a new issue at this stage. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 17 May 2013 13:35 To: uml25-ftf@omg.org Subject: RE: Notation for inherited, gray, UML DI, 18650 P.S. Also looks like UML DI will need to extended for all redefinable elements to enable interchange to tell whether the option to show inherited elements in lighter colors was used or not by the sender. Conrad Steve, Just remembered that UML DI has a property to tell whether inherited states should be shown in dashed, gray, or not different from others (these are the options currently given by state machine notation), see inheritedStateBorder on UMLStateDiagram in Figure B.13 (Behavior Diagrams). I assume this should be updated for the resolution of 18684. I need to go now, but will check back in the morning if you need me to provide the changes. Conrad From: "Bock, Conrad" To: "uml25-ftf@omg.org" Date: Fri, 17 May 2013 09:34:43 -0400 Subject: RE: Notation for inherited, gray, UML DI, 18650 Thread-Topic: Notation for inherited, gray, UML DI, 18650 Thread-Index: Ac5S+t2izLYBID7GRaGGiz8tuVSceQAALXfQAABXUFA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r4HDYlCu011505 X-Brightmail-Tracker: AAAAAR3FFAo= X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Steve, > I think you are right. Probably easiest to raise a new issue at this stage. The change would be to add the following text. I updated Classifier-low.doc, but haven't checked it in. It's good to avoid issues on earlier resolutions, but if people what to have more time to review it, I can put it in ballot 6. Conrad In Annex A (UML Diagram Interchange) In Figure B.3 (UML Diagrams and Diagram Elements), in UMLDiagram, add property at end "isInheritedLighter : Boolean = false". In the paragraph under the bullets under Figure B.3 (UML Diagrams and Diagram Elements), the one starting "UMLDiagram is the most general", at the end, add "UMLDiagram introduces isInheritedLighter to indicate whether inherited elements shall be shown in a lighter color.". In Figure B.13 (Behavior Diagrams), in UMLStateMachine, replace "inheritedStateBorder : UMLInheritedStateBorderKind [0..1]" with "isInheritedDashed : Boolean = false". Remove UMLInheritedStateBorderKind. In the paragraph under the bullets under Figure B.13 (Behavior Diagrams), the one starting "UMLStateMachineDiagrams are restricted", replace the last sentence with "It also introduces isInheritedDashed to indicate whether borders of UMLShapes that have an inherited State as modelElement shall be dashed. This property and isInheritedLighter cannot both have a value of true, and one of them must have a value of true for UMLStateMachineDiagrams that show inherited States. In Subclause B.6 (Classifier Descriptions), StateMachineDiagram, Constraints, replace the first bullet with two bullets: - isd_isl_xor isInheritedDashed and isInheritedLighter cannot both have a value of true. inv : not (isInheritedDashed and isInheritedLighter) - isd_isl_req Either isInheritedDashed or isInheritedLighter must have a value of true if the diagram shows any inherited states. From: "Bock, Conrad" To: Juergen Boldt Date: Fri, 17 May 2013 09:37:11 -0400 Subject: RE: Notation for inherited, gray, UML DI, 18650 Thread-Topic: Notation for inherited, gray, UML DI, 18650 Thread-Index: Ac5TA22NVfuBcHp2Tl+V4rYvX4jjTQAACiKg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r4HDbDrR011722 X-Brightmail-Tracker: AAAAAh3E5wUdxOb+ X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit > have an issue description/title? Might still go in this ballot. I'll file it if it doesn't. Conrad From: Steve Cook To: "Bock, Conrad" , "uml25-ftf@omg.org" , "Manfred R. Koethe (koethe@88solutions.com)" Subject: RE: Notation for inherited, gray, UML DI, 18650 Thread-Topic: Notation for inherited, gray, UML DI, 18650 Thread-Index: Ac5S+t2izLYBID7GRaGGiz8tuVSceQAALXfQAABXUFAAAaDX8A== Date: Fri, 17 May 2013 13:37:51 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(189002)(199002)(13464003)(31014003)(53806001)(69226001)(54356001)(49866001)(46102001)(4396001)(47736001)(47446002)(50986001)(63696002)(47776003)(79102001)(20776003)(6806003)(31966008)(74706001)(33656001)(74366001)(65816001)(74662001)(81342001)(47976001)(16406001)(74502001)(81542001)(80022001)(50466002)(55846006)(44976003)(23676002)(77982001)(56816002)(51856001)(74876001)(56776001)(76482001)(59766001)(54316002);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB031;H:TK5EX14HUBC102.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08497C3D99 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r4HDcBPc011798 X-Brightmail-Tracker: AAAAAR3FFAo= X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Works for me. I suggest you check it in, and hopefully Manfred can incorporate that change as well as the other rewording I proposed to encompass EnumerationLiterals, and the new picture I checked in. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 17 May 2013 14:31 To: uml25-ftf@omg.org Subject: RE: Notation for inherited, gray, UML DI, 18650 Steve, > I think you are right. Probably easiest to raise a new issue at this stage. The change would be to add the following text. I updated Classifier-low.doc, but haven't checked it in. It's good to avoid issues on earlier resolutions, but if people what to have more time to review it, I can put it in ballot 6. Conrad In Annex A (UML Diagram Interchange) In Figure B.3 (UML Diagrams and Diagram Elements), in UMLDiagram, add property at end "isInheritedLighter : Boolean = false". In the paragraph under the bullets under Figure B.3 (UML Diagrams and Diagram Elements), the one starting "UMLDiagram is the most general", at the end, add "UMLDiagram introduces isInheritedLighter to indicate whether inherited elements shall be shown in a lighter color.". In Figure B.13 (Behavior Diagrams), in UMLStateMachine, replace "inheritedStateBorder : UMLInheritedStateBorderKind [0..1]" with "isInheritedDashed : Boolean = false". Remove UMLInheritedStateBorderKind. In the paragraph under the bullets under Figure B.13 (Behavior Diagrams), the one starting "UMLStateMachineDiagrams are restricted", replace the last sentence with "It also introduces isInheritedDashed to indicate whether borders of UMLShapes that have an inherited State as modelElement shall be dashed. This property and isInheritedLighter cannot both have a value of true, and one of them must have a value of true for UMLStateMachineDiagrams that show inherited States. In Subclause B.6 (Classifier Descriptions), Constraints, replace the first bullet with two bullets: - isd_isl_xor isInheritedDashed and isInheritedLighter cannot both have a value of true. inv : not (isInheritedDashed and isInheritedLighter) - isd_isl_req Either isInheritedDashed or isInheritedLighter must have a value of true if the diagram shows any inherited states.