Issue 18132: UML2.5: clarification about the semantics of redefinition (uml25-ftf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: There are three closely related problems in this issue: 1) incorrect constraint in Structured Classifiers, clause 11, Connector: 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)) - The OCL constraint does not take into account the structured classifier's inherited roles. - The English constraint description is ambiguous whether inherited roles are to be included or not. 2) The structured classifier clause does not adequately explain the semantics of redefining parts and connectors. For structured classifiers with inherited parts and/or connectors and redefined parts and/or connectors, there are two views of a given structured classifier: The abstract syntax view which retains the abstract syntax distinction between a redefining element and a redefined element. The semantics view where all occurrences of a redefined element are replaced by its redefining element. Ed's message below explains the distinction between these two views. 3) More generally, the distinction between the abstract syntax view & the semantics view needs to be addressed for all kinds of redefineable elements; particularly those where the semantics of redefinition can have a significant impact on UML structure and behavior diagrams, including but not limited to: Class diagrams State machine diagrams Activity diagrams Interaction diagrams Etc Resolution: Revised Text: Actions taken: October 2, 2012: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: CUCCURU Arnaud , Ed Seidewitz , Steve Cook Subject: UML2.5: clarification about the semantics of redefinition. Thread-Topic: UML2.5: clarification about the semantics of redefinition. Thread-Index: AQHNoM5A/I/G2kAZm0+2grFRnSn9Pg== Date: Tue, 2 Oct 2012 18:46:36 +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 There are three closely related problems in this issue: 1) incorrect constraint in Structured Classifiers, clause 11, Connector: 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)) - The OCL constraint does not take into account the structured classifier's inherited roles. - The English constraint description is ambiguous whether inherited roles are to be included or not. 2) The structured classifier clause does not adequately explain the semantics of redefining parts and connectors. For structured classifiers with inherited parts and/or connectors and redefined parts and/or connectors, there are two views of a given structured classifier: The abstract syntax view which retains the abstract syntax distinction between a redefining element and a redefined element. The semantics view where all occurrences of a redefined element are replaced by its redefining element. Ed's message below explains the distinction between these two views. 3) More generally, the distinction between the abstract syntax view & the semantics view needs to be addressed for all kinds of redefineable elements; particularly those where the semantics of redefinition can have a significant impact on UML structure and behavior diagrams, including but not limited to: Class diagrams State machine diagrams Activity diagrams Interaction diagrams Etc - Nicolas. From: Ed Seidewitz Date: Wednesday, September 19, 2012 8:49 AM To: CUCCURU Arnaud Cc: JPL , Bran Selic , Sanford Friedenthal , "BERNARD, Yves" , Burkhart Roger M , Conrad Bock , "semanticsofcomposites@omg.org" , Nerijus Jankevicius Subject: RE: Summary of the Initial submitters meeting at Jacksonville Arnaud . Actually, I don.t think the Connector::roles constraint you identify would require the redefinition of the connector in the Nicolas.s examples. At most, the constraint implies that, if a connector is redefined, then the roles it connects also need to be redefined. To see this, let.s do a detailed analysis of Nicolas. example against the spec (primarily the UML 2.5 spec, since this is the one with the constraints properly worked out, such as the one you quoted). In Nicolas. example, block U has three owned members: partA, partB and x. These are all inheritable. Block V inherits partA and x, but, as has been previously noted, it does not inherit partB. Rather, it redefines partB as partD. So, V also has three members: partA, partD and x, but it only owns partD. What, then, is the status of connector x relative to block V? Since x is inherited by V, V::x is just another name for U::x. Therefore, V::x still connects U::partA and U::partB. Since x is owned by V and partA and partB are all owned attributes (and, hence, roles) of V, the Connector::roles constraint you quoted is not violated. (On the other hand, if V redefined x, then the ends of the redefining connector would need, by this constraint, to be roles of V and could no longer be V::partA and V::partB . but could be redefinitions of them.) Now, V inherits partA, but it no longer has a partB. So what are the semantics of V::x when V is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of U::partB by V::partD). 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 W, we also get objects instantiated in V::partA and V::partD and a link instantiated for x. The link for x connects the objects in U::partA and U::partB. However, in the context of V, this .reference. to the .redefined member. U::partB .resolves. to the .redefining member. V::partD. That is, in the context of V, the link instantiated for x will connect the objects in V::partA and V::partD, even though the connector x still has U::partA and U::partB on its ends. And this is type safe, since D (the type of partD) is required to be a subtype of B (the type of partB). The bottom line is that it is not the case that V::x connects V::partA and V::partD syntactically in the model. V::x is just U::x as inherited by V, and this cannot change the syntactic structure of x, which is to connect V::partA and V::partB. So, the comment on Nicolas. diagrams that .This should be shown as connecting partA with partD. is not correct. However, semantically it is the case that the link instantiated for x in the context of an instance of V will connect the objects instantiated in V::partA and V::partD. So, Nicolas. statement in his email that .In the context of V, U::x (which is an inherited feature for V) means that U::partA is connected to V::partD according to the association AB. is correct, in this semantic sense. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in Nicolas. examples! Finally, I wanted to also note that redefinition of properties is actually not included in the fUML subset (largely because, before UML 2.5, the UML semantics didn.t explicitly state the key point used above to define the semantics of property redefinition, so it wasn.t clear what the semantics where!). Adding property redefinition to fUML is not specific to composite structures and should be handled as an fUML issue. Therefore, this is not something we need to deal with for our submission on the semantics of composite structure . unless, of course, we want to define the semantics of the redefinition of connectors (which would be specific to composite structures). However, I definitely don.t think this is something we want to get into for the initial submission, so, for that submission at least, I recommend that we also exclude connector redefinition from our subset for composite structure semantics (that is, we should require that Connector::redefinedConnector be empty). -- Ed From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: Wednesday, September 19, 2012 8:04 AM To: Nerijus Jankevicius Cc: Rouquette, Nicolas F (313K); Bran Selic; Sanford Friedenthal; BERNARD, Yves; Burkhart Roger M; Bock, Conrad; Ed Seidewitz; semanticsofcomposites@omg.org Subject: RE: Summary of the Initial submitters meeting at Jacksonville I have checked in the spec, and there is a constraint associated with Connector which also requires the connector to be redefined in the examples: 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)) and StructuredClassifier.role subsets Namespace.member Arnaud CUCCURU CEA LIST, Ingéeur chercheur Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Tel : + 33 1 69 08 49 61 Fax : + 33 1 69 08 20 82 De : Nerijus Jankevicius [mailto:nerijus@nomagic.com] Envoyé mercredi 19 septembre 2012 13:46 À: CUCCURU Arnaud Cc : Rouquette, Nicolas F (313K); Bran Selic; Sanford Friedenthal; BERNARD, Yves; Burkhart Roger M; Bock, Conrad; Ed Seidewitz; semanticsofcomposites@omg.org Objet : Re: Summary of the Initial submitters meeting at Jacksonville Arnaud, I second what you say - redefined properties are not visible in new namespace. They are REDEFINED, not available, lost. They should not be displayed in specialized class IBD too. I do not agree that connectors should be "inherited". It is weird interpretation of redefinition. If you say Connector is typed by Association and ends are redefined, that means you should have specialization of Association too, so probably new Connectors should be created and typed by this specialized Association. -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Sep 19, 2012, at 2:39 PM, CUCCURU Arnaud wrote: Hi Nicolas, Independently of the connector issue, is it correct to show partA in block W / partB in block V? Showing these parts suggest that they are inherited by W / V, and it seems that they should not be inherited (cf. operation inherit() of Class, which according to UML 2.5 is overridden to exclude redefined properties). If the interpretation above is correct, I suppose that block W and V should introduce new connectors which explicitly redefine connector x, where each connector should be between the inherited part and the redefined part. Cheers, Arnaud CUCCURU CEA LIST, Ingéeur chercheur Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Tel : + 33 1 69 08 49 61 Fax : + 33 1 69 08 20 82 De : Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Envoyé mercredi 19 septembre 2012 04:18 À: Bran Selic; Sanford Friedenthal Cc : CUCCURU Arnaud; BERNARD, Yves; nerijus@nomagic.com; Burkhart Roger M; Bock, Conrad; Ed Seidewitz; semanticsofcomposites@omg.org Objet : Re: Summary of the Initial submitters meeting at Jacksonville Bran, Whether a connector is typed or not is a secondary consideration to what happens when some or all of the connected parts are redefined but the connector itself isn't redefined. This problem is inherently tied to the interaction between the semantics of structured classifier specialization (in this example, V and W specialize U) and of redefinable features (I.e., connectors & parts) I have attached a variant of the problem where the connector U::x between U::partA and U::partB is untyped. The clarification question I'm raising is what is true for V and W as specializations of the structured classifier U, particularly: For V, is it true that U::x (an inherited connector feature) connects the inherited part feature U::partA with the redefining part feature V::partD (instead of the redefined part feature U::partB)? For W, is it true that U::x (an inherited connector feature) connects the redefining part feature W::partC (instead of the inherited part feature U::partA) with the inherited part feature U::partB? I would like to confirm the answer must be anything but yes. - Nicolas. From: Bran Selic Date: Tuesday, September 18, 2012 6:11 PM To: Sanford Friedenthal Cc: JPL , CUCCURU Arnaud , "BERNARD, Yves" , Nerijus Jankevicius , Burkhart Roger M , Conrad Bock , Ed Seidewitz , "semanticsofcomposites@omg.org" Subject: Re: Summary of the Initial submitters meeting at Jacksonville OTOH, if we allowed untyped connectors, I think that this particular problem would go away. We are really seeing the consequences of overgeneralization. The concept of connectors in architectural description languages, where it originated, was that of a simple pipe-like structural element. (Thus, there was no fundamental need to type connectors, the only thing that mattered were the types of what was attached at the ends of the connectors.) Associations, on the other hand, as we well know by now, are complex multifarious beasts representing a wide variety of very different things and their semantics have been stretched even further when the concept subsumed both UML and SysML connectors. In retrospect, I think it would have made more sense had we introduced an abstract "attachment" concept that was then specialized into Associations and Connectors, rather than bundling everything into Association. Something for the next gen modeling languages to consider, I suppose. Cheers...Bran On Tue, Sep 18, 2012 at 1:39 PM, Sanford Friedenthal wrote: Nicolas Ok. I see your intent. Thx. I look forward to hearing any other responses to this observation. Sandy From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, September 18, 2012 1:12 PM To: Sanford Friedenthal; 'CUCCURU Arnaud'; 'BERNARD, Yves' Cc: nerijus@nomagic.com; 'Burkhart Roger M'; 'Bock, Conrad'; 'Ed Seidewitz'; semanticsofcomposites@omg.org Subject: Re: Summary of the Initial submitters meeting at Jacksonville Sandy, I defined AB according to the SysML modeling conventions; that is, the association-owned end, AB::a, is semantically derived as the inverse of the class-owned end, A::b So technically, I should have shown AB::/a instead of AB::a but this would add unnecessary distraction to the main point. The main point is that the semantics of a particular connector . e.g., U::x . is subtly tied to the context of a structured classifier. For example, in the context of U, U::x means that U::partA is connected to U::partB according to the association AB In the context of V, U::x (which is an inherited feature for V) means that U::partA is connected to V::partD according to the association AB In the context of W, U::x (which is an inherited feature for W) means that W::partC is connected to U::partB according to the association AB This is particularly important to clarify this in the spec so that UML/SysML tool vendors implement the right support for UML's structure diagrams and SysML's IBDs. In fact, I would be surprised if there is any UML/SysML tool out there that supports this subtle combinations of connector & redefinition semantics. Nicolas. From: Sanford Friedenthal Date: Tuesday, September 18, 2012 9:53 AM To: JPL , 'CUCCURU Arnaud' , "BERNARD, Yves" Cc: Nerijus Jankevicius , Burkhart Roger M , Conrad Bock , Ed Seidewitz , "semanticsofcomposites@omg.org" Subject: RE: Summary of the Initial submitters meeting at Jacksonville Should the association AB be two way navigable instead of one way? I would agree with your interpretation of how you redefine the inherited connector x:AB. Sandy From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, September 18, 2012 12:26 PM To: CUCCURU Arnaud; BERNARD, Yves; Sanford Friedenthal Cc: nerijus@nomagic.com; 'Burkhart Roger M'; 'Bock, Conrad'; 'Ed Seidewitz'; semanticsofcomposites@omg.org Subject: Re: Summary of the Initial submitters meeting at Jacksonville System engineers at JPL are asking questions about the semantics of connectors when redefinitions are involved. There are many cases: connectors between parts vs. ports vs. combinations of both Connectors typed by associations or not Redefinitions of connected parts vs. redefinitions of parts with connected ports vs. redefinition of connected ports vs redefinition of parts with redefined connected ports In these combinations, the question is whether we have to redefine a connector or not. The spec is not clear on this. The simplest example is where we have a connector among parts (or ports) and some parts (or ports) are redefined but not the connector itself. The attached diagram shows a class U with 2 connected parts. Class V and W specialize U and redefines only one of the connected parts. There is no connector redefinition; but V and W inherit U's connector. The question then is what is the semantics of the inherited connector in the specialized classes? I believe that the meaning of the inherited connector should be that of connecting the redefining parts (instead of the inherited, redefined parts as done in the parent class U). I've attached a diagram to illustrate this problem. Comments? - Nicolas From: Ed Seidewitz To: "Rouquette, Nicolas F (313K)" CC: CUCCURU Arnaud , Steve Cook , "issues@omg.org" Date: Tue, 2 Oct 2012 15:37:29 -0400 Subject: RE: UML2.5: clarification about the semantics of redefinition. Thread-Topic: UML2.5: clarification about the semantics of redefinition. Thread-Index: AQHNoM5A/I/G2kAZm0+2grFRnSn9PpemZTtA 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.225]|10.1.50.225|outbound.mailprotector.net|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: null_ptr subject_50_chars clean X-Mailprotector-Score: 60 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0.835348 p=-0.976471 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-Mailprotector-ID: ee953e44-02bb-426a-b7e4-e564b69757af Nicolas . Well, actually, I don.t think there really is any such thing as an .inherited role., at least as the UML abstract syntax is currently defined. StructuredClassifier::role is a derived union, and the only thing in StructuredClassifier that subsets it is ownedAttribute (in Collaboration, collaborationRole also subsets it). Thus, strictly speaking, (for Classes, at least), the roles of a StructuredClassifier must be ownedAttributes. Now, I suppose that one could consider these to be .owned roles. and treat inherited attributes (which are roles of superclasses) as .inherited roles., but nothing in the current syntax or semantics for StucturedClassifiers or Connectors does that. -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, October 02, 2012 2:47 PM To: issues@omg.org Cc: CUCCURU Arnaud; Ed Seidewitz; Steve Cook Subject: UML2.5: clarification about the semantics of redefinition. There are three closely related problems in this issue: 1) incorrect constraint in Structured Classifiers, clause 11, Connector: 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)) - The OCL constraint does not take into account the structured classifier's inherited roles. - The English constraint description is ambiguous whether inherited roles are to be included or not. 2) The structured classifier clause does not adequately explain the semantics of redefining parts and connectors. For structured classifiers with inherited parts and/or connectors and redefined parts and/or connectors, there are two views of a given structured classifier: The abstract syntax view which retains the abstract syntax distinction between a redefining element and a redefined element. The semantics view where all occurrences of a redefined element are replaced by its redefining element. Ed's message below explains the distinction between these two views. 3) More generally, the distinction between the abstract syntax view & the semantics view needs to be addressed for all kinds of redefineable elements; particularly those where the semantics of redefinition can have a significant impact on UML structure and behavior diagrams, including but not limited to: Class diagrams State machine diagrams Activity diagrams Interaction diagrams Etc - Nicolas. From: Ed Seidewitz Date: Wednesday, September 19, 2012 8:49 AM To: CUCCURU Arnaud Cc: JPL , Bran Selic , Sanford Friedenthal , "BERNARD, Yves" , Burkhart Roger M , Conrad Bock , "semanticsofcomposites@omg.org" , Nerijus Jankevicius Subject: RE: Summary of the Initial submitters meeting at Jacksonville Arnaud . Actually, I don.t think the Connector::roles constraint you identify would require the redefinition of the connector in the Nicolas.s examples. At most, the constraint implies that, if a connector is redefined, then the roles it connects also need to be redefined. To see this, let.s do a detailed analysis of Nicolas. example against the spec (primarily the UML 2.5 spec, since this is the one with the constraints properly worked out, such as the one you quoted). In Nicolas. example, block U has three owned members: partA, partB and x. These are all inheritable. Block V inherits partA and x, but, as has been previously noted, it does not inherit partB. Rather, it redefines partB as partD. So, V also has three members: partA, partD and x, but it only owns partD. What, then, is the status of connector x relative to block V? Since x is inherited by V, V::x is just another name for U::x. Therefore, V::x still connects U::partA and U::partB. Since x is owned by V and partA and partB are all owned attributes (and, hence, roles) of V, the Connector::roles constraint you quoted is not violated. (On the other hand, if V redefined x, then the ends of the redefining connector would need, by this constraint, to be roles of V and could no longer be V::partA and V::partB . but could be redefinitions of them.) Now, V inherits partA, but it no longer has a partB. So what are the semantics of V::x when V is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of U::partB by V::partD). 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 W, we also get objects instantiated in V::partA and V::partD and a link instantiated for x. The link for x connects the objects in U::partA and U::partB. However, in the context of V, this .reference. to the .redefined member. U::partB .resolves. to the .redefining member. V::partD. That is, in the context of V, the link instantiated for x will connect the objects in V::partA and V::partD, even though the connector x still has U::partA and U::partB on its ends. And this is type safe, since D (the type of partD) is required to be a subtype of B (the type of partB). The bottom line is that it is not the case that V::x connects V::partA and V::partD syntactically in the model. V::x is just U::x as inherited by V, and this cannot change the syntactic structure of x, which is to connect V::partA and V::partB. So, the comment on Nicolas. diagrams that .This should be shown as connecting partA with partD. is not correct. However, semantically it is the case that the link instantiated for x in the context of an instance of V will connect the objects instantiated in V::partA and V::partD. So, Nicolas. statement in his email that .In the context of V, U::x (which is an inherited feature for V) means that U::partA is connected to V::partD according to the association AB. is correct, in this semantic sense. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in Nicolas. examples! Finally, I wanted to also note that redefinition of properties is actually not included in the fUML subset (largely because, before UML 2.5, the UML semantics didn.t explicitly state the key point used above to define the semantics of property redefinition, so it wasn.t clear what the semantics where!). Adding property redefinition to fUML is not specific to composite structures and should be handled as an fUML issue. Therefore, this is not something we need to deal with for our submission on the semantics of composite structure . unless, of course, we want to define the semantics of the redefinition of connectors (which would be specific to composite structures). However, I definitely don.t think this is something we want to get into for the initial submission, so, for that submission at least, I recommend that we also exclude connector redefinition from our subset for composite structure semantics (that is, we should require that Connector::redefinedConnector be empty). -- Ed From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: Wednesday, September 19, 2012 8:04 AM To: Nerijus Jankevicius Cc: Rouquette, Nicolas F (313K); Bran Selic; Sanford Friedenthal; BERNARD, Yves; Burkhart Roger M; Bock, Conrad; Ed Seidewitz; semanticsofcomposites@omg.org Subject: RE: Summary of the Initial submitters meeting at Jacksonville I have checked in the spec, and there is a constraint associated with Connector which also requires the connector to be redefined in the examples: 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)) and StructuredClassifier.role subsets Namespace.member Arnaud CUCCURU CEA LIST, Ingéeur chercheur Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Tel : + 33 1 69 08 49 61 Fax : + 33 1 69 08 20 82 De : Nerijus Jankevicius [mailto:nerijus@nomagic.com] Envoyé mercredi 19 septembre 2012 13:46 À: CUCCURU Arnaud Cc : Rouquette, Nicolas F (313K); Bran Selic; Sanford Friedenthal; BERNARD, Yves; Burkhart Roger M; Bock, Conrad; Ed Seidewitz; semanticsofcomposites@omg.org Objet : Re: Summary of the Initial submitters meeting at Jacksonville Arnaud, I second what you say - redefined properties are not visible in new namespace. They are REDEFINED, not available, lost. They should not be displayed in specialized class IBD too. I do not agree that connectors should be "inherited". It is weird interpretation of redefinition. If you say Connector is typed by Association and ends are redefined, that means you should have specialization of Association too, so probably new Connectors should be created and typed by this specialized Association. -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Sep 19, 2012, at 2:39 PM, CUCCURU Arnaud wrote: Hi Nicolas, Independently of the connector issue, is it correct to show partA in block W / partB in block V? Showing these parts suggest that they are inherited by W / V, and it seems that they should not be inherited (cf. operation inherit() of Class, which according to UML 2.5 is overridden to exclude redefined properties). If the interpretation above is correct, I suppose that block W and V should introduce new connectors which explicitly redefine connector x, where each connector should be between the inherited part and the redefined part. Cheers, Arnaud CUCCURU CEA LIST, Ingéeur chercheur Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Tel : + 33 1 69 08 49 61 Fax : + 33 1 69 08 20 82 De : Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Envoyé mercredi 19 septembre 2012 04:18 À: Bran Selic; Sanford Friedenthal Cc : CUCCURU Arnaud; BERNARD, Yves; nerijus@nomagic.com; Burkhart Roger M; Bock, Conrad; Ed Seidewitz; semanticsofcomposites@omg.org Objet : Re: Summary of the Initial submitters meeting at Jacksonville Bran, Whether a connector is typed or not is a secondary consideration to what happens when some or all of the connected parts are redefined but the connector itself isn't redefined. This problem is inherently tied to the interaction between the semantics of structured classifier specialization (in this example, V and W specialize U) and of redefinable features (I.e., connectors & parts) I have attached a variant of the problem where the connector U::x between U::partA and U::partB is untyped. The clarification question I'm raising is what is true for V and W as specializations of the structured classifier U, particularly: For V, is it true that U::x (an inherited connector feature) connects the inherited part feature U::partA with the redefining part feature V::partD (instead of the redefined part feature U::partB)? For W, is it true that U::x (an inherited connector feature) connects the redefining part feature W::partC (instead of the inherited part feature U::partA) with the inherited part feature U::partB? I would like to confirm the answer must be anything but yes. - Nicolas. From: Bran Selic Date: Tuesday, September 18, 2012 6:11 PM To: Sanford Friedenthal Cc: JPL , CUCCURU Arnaud , "BERNARD, Yves" , Nerijus Jankevicius , Burkhart Roger M , Conrad Bock , Ed Seidewitz , "semanticsofcomposites@omg.org" Subject: Re: Summary of the Initial submitters meeting at Jacksonville OTOH, if we allowed untyped connectors, I think that this particular problem would go away. We are really seeing the consequences of overgeneralization. The concept of connectors in architectural description languages, where it originated, was that of a simple pipe-like structural element. (Thus, there was no fundamental need to type connectors, the only thing that mattered were the types of what was attached at the ends of the connectors.) Associations, on the other hand, as we well know by now, are complex multifarious beasts representing a wide variety of very different things and their semantics have been stretched even further when the concept subsumed both UML and SysML connectors. In retrospect, I think it would have made more sense had we introduced an abstract "attachment" concept that was then specialized into Associations and Connectors, rather than bundling everything into Association. Something for the next gen modeling languages to consider, I suppose. Cheers...Bran On Tue, Sep 18, 2012 at 1:39 PM, Sanford Friedenthal wrote: Nicolas Ok. I see your intent. Thx. I look forward to hearing any other responses to this observation. Sandy From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, September 18, 2012 1:12 PM To: Sanford Friedenthal; 'CUCCURU Arnaud'; 'BERNARD, Yves' Cc: nerijus@nomagic.com; 'Burkhart Roger M'; 'Bock, Conrad'; 'Ed Seidewitz'; semanticsofcomposites@omg.org Subject: Re: Summary of the Initial submitters meeting at Jacksonville Sandy, I defined AB according to the SysML modeling conventions; that is, the association-owned end, AB::a, is semantically derived as the inverse of the class-owned end, A::b So technically, I should have shown AB::/a instead of AB::a but this would add unnecessary distraction to the main point. The main point is that the semantics of a particular connector . e.g., U::x . is subtly tied to the context of a structured classifier. For example, in the context of U, U::x means that U::partA is connected to U::partB according to the association AB In the context of V, U::x (which is an inherited feature for V) means that U::partA is connected to V::partD according to the association AB In the context of W, U::x (which is an inherited feature for W) means that W::partC is connected to U::partB according to the association AB This is particularly important to clarify this in the spec so that UML/SysML tool vendors implement the right support for UML's structure diagrams and SysML's IBDs. In fact, I would be surprised if there is any UML/SysML tool out there that supports this subtle combinations of connector & redefinition semantics. Nicolas. From: Sanford Friedenthal Date: Tuesday, September 18, 2012 9:53 AM To: JPL , 'CUCCURU Arnaud' , "BERNARD, Yves" Cc: Nerijus Jankevicius , Burkhart Roger M , Conrad Bock , Ed Seidewitz , "semanticsofcomposites@omg.org" Subject: RE: Summary of the Initial submitters meeting at Jacksonville Should the association AB be two way navigable instead of one way? I would agree with your interpretation of how you redefine the inherited connector x:AB. Sandy From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, September 18, 2012 12:26 PM To: CUCCURU Arnaud; BERNARD, Yves; Sanford Friedenthal Cc: nerijus@nomagic.com; 'Burkhart Roger M'; 'Bock, Conrad'; 'Ed Seidewitz'; semanticsofcomposites@omg.org Subject: Re: Summary of the Initial submitters meeting at Jacksonville System engineers at JPL are asking questions about the semantics of connectors when redefinitions are involved. There are many cases: connectors between parts vs. ports vs. combinations of both Connectors typed by associations or not Redefinitions of connected parts vs. redefinitions of parts with connected ports vs. redefinition of connected ports vs redefinition of parts with redefined connected ports In these combinations, the question is whether we have to redefine a connector or not. The spec is not clear on this. The simplest example is where we have a connector among parts (or ports) and some parts (or ports) are redefined but not the connector itself. The attached diagram shows a class U with 2 connected parts. Class V and W specialize U and redefines only one of the connected parts. There is no connector redefinition; but V and W inherit U's connector. The question then is what is the semantics of the inherited connector in the specialized classes? I believe that the meaning of the inherited connector should be that of connecting the redefining parts (instead of the inherited, redefined parts as done in the parent class U). I've attached a diagram to illustrate this problem. Comments? - Nicolas From: "Rouquette, Nicolas F (313K)" To: Ed Seidewitz CC: CUCCURU Arnaud , Steve Cook , "issues@omg.org" Subject: Re: UML2.5: clarification about the semantics of redefinition. Thread-Topic: UML2.5: clarification about the semantics of redefinition. Thread-Index: AQHNoM5A/I/G2kAZm0+2grFRnSn9PpemZTtAgAAi2gA= Date: Tue, 2 Oct 2012 21:28:24 +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 Ed, The spec is clearly written from the point of view where "role", "part" and "end" have only a meaning for the "owning" classifier of properties, connectable elements, connectors and connector ends. From a practical point of view, the spec does not explain what happens with specializations of structured classifiers. I believe the spec needs to address this explicitly by explaining what's going on at the abstract syntax level and also at the semantic level; that is: - the effective parts in a classifier (owned or inherited) - the effective connectors (owned or inherited) - the effective connection topology (what is effectively connected to what, taking into account redefinitions of parts, roles and connectors) Consider a simple example where a structured classifier A has just 1 owned attribute: A::p1 The following is true about the abstract syntax: A./role = A::p1 A./part = A::p1 A./feature = A::p1 Consider another structured classifier B that specializes A and defines its own attribute: B::p2 The following is true about the abstract syntax: A./role = A:: p1 A./part = A::p1 A./feature = A::p1 B./role = B::p2 B./part = B::p2 This means that we cannot connect B's inherited attribute A::p1 to B's own attribute B::p2 To connect them, we have to use redefinition; for example: B::p1 { redefines A::p1 } Then, we can create a connector B::p1_p2 where: B::p1_p2::end = B::p1, B::p2 The following is true about the abstract syntax: A./role = A::p1 A./part = A::p1 A./feature = A::p1 A.allFeatures() = A::p1 A.allAttributes() = A::p1 B./role = B::p1, B::p2 B./part = B::p1, B::p2 B./feature = B::p1, B::p2, B::p1_p2 B.allFeatures() = A::p1, B::p1, B::p2, B::p1_p2 B.allAttributes() = B::p1, B::p2 So far, it seems the spec would be fine. However, when you introduce connectors, then UML becomes just weirdly twisted. Suppose we add a 3rd structured classifier, C that specializes B and defines its own attribute: C::p3 { redefines B::p2 } The following is true about the abstract syntax: A./role = A::p1 A./part = A::p1 A./feature = A::p1 A.allFeatures() = A::p1 A.allAttributes() = A::p1 A.ownedConnector = null B./role = B::p1, B::p2 B./part = B::p1, B::p2 B./feature = B::p1, B::p2, B::p1_p2 B.allFeatures() = A::p1, B::p1, B::p2, B::p1_p2 B.allAttributes() = B::p1, B::p2 B.ownedConnector = B::p1_p2 C./role = C::p3 C./part = C::p3 C./feature = A::p1, B::p1, B::p2, B::p1_p2, C::p3 C.allFeatures() = C::p3 C.allAttributes() = A::p1, B::p1, B::p2, C::p3 C.ownedConnector = null I believe the above explanations are lacking in UML. Instead of expecting users to figure out how all of the aspects of UML work in combination, we should explain the key combinations with simple examples like the ones above. There are currently very few examples about the combination of generalization and redefinition in the spec that are explained in terms of what can be done and can't be done as I've done above. We should have MIWG test cases about these combinations and verify that interoperable tools do agree about the valid assertions about abstract syntax and effective semantics. - Nicolas. From: Ed Seidewitz Date: Tuesday, October 2, 2012 12:37 PM To: JPL Cc: CUCCURU Arnaud , Steve Cook , "issues@omg.org" Subject: RE: UML2.5: clarification about the semantics of redefinition. Nicolas . Well, actually, I don.t think there really is any such thing as an .inherited role., at least as the UML abstract syntax is currently defined. StructuredClassifier::role is a derived union, and the only thing in StructuredClassifier that subsets it is ownedAttribute (in Collaboration, collaborationRole also subsets it). Thus, strictly speaking, (for Classes, at least), the roles of a StructuredClassifier must be ownedAttributes. Now, I suppose that one could consider these to be .owned roles. and treat inherited attributes (which are roles of superclasses) as .inherited roles., but nothing in the current syntax or semantics for StucturedClassifiers or Connectors does that. -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, October 02, 2012 2:47 PM To: issues@omg.org Cc: CUCCURU Arnaud; Ed Seidewitz; Steve Cook Subject: UML2.5: clarification about the semantics of redefinition. There are three closely related problems in this issue: 1) incorrect constraint in Structured Classifiers, clause 11, Connector: 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)) - The OCL constraint does not take into account the structured classifier's inherited roles. - The English constraint description is ambiguous whether inherited roles are to be included or not. 2) The structured classifier clause does not adequately explain the semantics of redefining parts and connectors. For structured classifiers with inherited parts and/or connectors and redefined parts and/or connectors, there are two views of a given structured classifier: The abstract syntax view which retains the abstract syntax distinction between a redefining element and a redefined element. The semantics view where all occurrences of a redefined element are replaced by its redefining element. Ed's message below explains the distinction between these two views. 3) More generally, the distinction between the abstract syntax view & the semantics view needs to be addressed for all kinds of redefineable elements; particularly those where the semantics of redefinition can have a significant impact on UML structure and behavior diagrams, including but not limited to: Class diagrams State machine diagrams Activity diagrams Interaction diagrams Etc - Nicolas. From: Ed Seidewitz Date: Wednesday, September 19, 2012 8:49 AM To: CUCCURU Arnaud Cc: JPL , Bran Selic , Sanford Friedenthal , "BERNARD, Yves" , Burkhart Roger M , Conrad Bock , "semanticsofcomposites@omg.org" , Nerijus Jankevicius Subject: RE: Summary of the Initial submitters meeting at Jacksonville Arnaud . Actually, I don.t think the Connector::roles constraint you identify would require the redefinition of the connector in the Nicolas.s examples. At most, the constraint implies that, if a connector is redefined, then the roles it connects also need to be redefined. To see this, let.s do a detailed analysis of Nicolas. example against the spec (primarily the UML 2.5 spec, since this is the one with the constraints properly worked out, such as the one you quoted). In Nicolas. example, block U has three owned members: partA, partB and x. These are all inheritable. Block V inherits partA and x, but, as has been previously noted, it does not inherit partB. Rather, it redefines partB as partD. So, V also has three members: partA, partD and x, but it only owns partD. What, then, is the status of connector x relative to block V? Since x is inherited by V, V::x is just another name for U::x. Therefore, V::x still connects U::partA and U::partB. Since x is owned by V and partA and partB are all owned attributes (and, hence, roles) of V, the Connector::roles constraint you quoted is not violated. (On the other hand, if V redefined x, then the ends of the redefining connector would need, by this constraint, to be roles of V and could no longer be V::partA and V::partB . but could be redefinitions of them.) Now, V inherits partA, but it no longer has a partB. So what are the semantics of V::x when V is instantiated? Well, this depends on the semantics of the redefinition of a property (e.g., the redefinition of U::partB by V::partD). 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 W, we also get objects instantiated in V::partA and V::partD and a link instantiated for x. The link for x connects the objects in U::partA and U::partB. However, in the context of V, this .reference. to the .redefined member. U::partB .resolves. to the .redefining member. V::partD. That is, in the context of V, the link instantiated for x will connect the objects in V::partA and V::partD, even though the connector x still has U::partA and U::partB on its ends. And this is type safe, since D (the type of partD) is required to be a subtype of B (the type of partB). The bottom line is that it is not the case that V::x connects V::partA and V::partD syntactically in the model. V::x is just U::x as inherited by V, and this cannot change the syntactic structure of x, which is to connect V::partA and V::partB. So, the comment on Nicolas. diagrams that .This should be shown as connecting partA with partD. is not correct. However, semantically it is the case that the link instantiated for x in the context of an instance of V will connect the objects instantiated in V::partA and V::partD. So, Nicolas. statement in his email that .In the context of V, U::x (which is an inherited feature for V) means that U::partA is connected to V::partD according to the association AB. is correct, in this semantic sense. And, amazingly enough, I believe this is just about exactly what one would expect intuitively from the redefinitions shown in Nicolas. examples! Finally, I wanted to also note that redefinition of properties is actually not included in the fUML subset (largely because, before UML 2.5, the UML semantics didn.t explicitly state the key point used above to define the semantics of property redefinition, so it wasn.t clear what the semantics where!). Adding property redefinition to fUML is not specific to composite structures and should be handled as an fUML issue. Therefore, this is not something we need to deal with for our submission on the semantics of composite structure . unless, of course, we want to define the semantics of the redefinition of connectors (which would be specific to composite structures). However, I definitely don.t think this is something we want to get into for the initial submission, so, for that submission at least, I recommend that we also exclude connector redefinition from our subset for composite structure semantics (that is, we should require that Connector::redefinedConnector be empty). -- Ed From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: Wednesday, September 19, 2012 8:04 AM To: Nerijus Jankevicius Cc: Rouquette, Nicolas F (313K); Bran Selic; Sanford Friedenthal; BERNARD, Yves; Burkhart Roger M; Bock, Conrad; Ed Seidewitz; semanticsofcomposites@omg.org Subject: RE: Summary of the Initial submitters meeting at Jacksonville I have checked in the spec, and there is a constraint associated with Connector which also requires the connector to be redefined in the examples: 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)) and StructuredClassifier.role subsets Namespace.member Arnaud CUCCURU CEA LIST, Ingéeur chercheur Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Tel : + 33 1 69 08 49 61 Fax : + 33 1 69 08 20 82 De : Nerijus Jankevicius [mailto:nerijus@nomagic.com] Envoyé mercredi 19 septembre 2012 13:46 À: CUCCURU Arnaud Cc : Rouquette, Nicolas F (313K); Bran Selic; Sanford Friedenthal; BERNARD, Yves; Burkhart Roger M; Bock, Conrad; Ed Seidewitz; semanticsofcomposites@omg.org Objet : Re: Summary of the Initial submitters meeting at Jacksonville Arnaud, I second what you say - redefined properties are not visible in new namespace. They are REDEFINED, not available, lost. They should not be displayed in specialized class IBD too. I do not agree that connectors should be "inherited". It is weird interpretation of redefinition. If you say Connector is typed by Association and ends are redefined, that means you should have specialization of Association too, so probably new Connectors should be created and typed by this specialized Association. -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! On Sep 19, 2012, at 2:39 PM, CUCCURU Arnaud wrote: Hi Nicolas, Independently of the connector issue, is it correct to show partA in block W / partB in block V? Showing these parts suggest that they are inherited by W / V, and it seems that they should not be inherited (cf. operation inherit() of Class, which according to UML 2.5 is overridden to exclude redefined properties). If the interpretation above is correct, I suppose that block W and V should introduce new connectors which explicitly redefine connector x, where each connector should be between the inherited part and the redefined part. Cheers, Arnaud CUCCURU CEA LIST, Ingéeur chercheur Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Tel : + 33 1 69 08 49 61 Fax : + 33 1 69 08 20 82 De : Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Envoyé mercredi 19 septembre 2012 04:18 À: Bran Selic; Sanford Friedenthal Cc : CUCCURU Arnaud; BERNARD, Yves; nerijus@nomagic.com; Burkhart Roger M; Bock, Conrad; Ed Seidewitz; semanticsofcomposites@omg.org Objet : Re: Summary of the Initial submitters meeting at Jacksonville Bran, Whether a connector is typed or not is a secondary consideration to what happens when some or all of the connected parts are redefined but the connector itself isn't redefined. This problem is inherently tied to the interaction between the semantics of structured classifier specialization (in this example, V and W specialize U) and of redefinable features (I.e., connectors & parts) I have attached a variant of the problem where the connector U::x between U::partA and U::partB is untyped. The clarification question I'm raising is what is true for V and W as specializations of the structured classifier U, particularly: For V, is it true that U::x (an inherited connector feature) connects the inherited part feature U::partA with the redefining part feature V::partD (instead of the redefined part feature U::partB)? For W, is it true that U::x (an inherited connector feature) connects the redefining part feature W::partC (instead of the inherited part feature U::partA) with the inherited part feature U::partB? I would like to confirm the answer must be anything but yes. - Nicolas. From: Bran Selic Date: Tuesday, September 18, 2012 6:11 PM To: Sanford Friedenthal Cc: JPL , CUCCURU Arnaud , "BERNARD, Yves" , Nerijus Jankevicius , Burkhart Roger M , Conrad Bock , Ed Seidewitz , "semanticsofcomposites@omg.org" Subject: Re: Summary of the Initial submitters meeting at Jacksonville OTOH, if we allowed untyped connectors, I think that this particular problem would go away. We are really seeing the consequences of overgeneralization. The concept of connectors in architectural description languages, where it originated, was that of a simple pipe-like structural element. (Thus, there was no fundamental need to type connectors, the only thing that mattered were the types of what was attached at the ends of the connectors.) Associations, on the other hand, as we well know by now, are complex multifarious beasts representing a wide variety of very different things and their semantics have been stretched even further when the concept subsumed both UML and SysML connectors. In retrospect, I think it would have made more sense had we introduced an abstract "attachment" concept that was then specialized into Associations and Connectors, rather than bundling everything into Association. Something for the next gen modeling languages to consider, I suppose. Cheers...Bran On Tue, Sep 18, 2012 at 1:39 PM, Sanford Friedenthal wrote: Nicolas Ok. I see your intent. Thx. I look forward to hearing any other responses to this observation. Sandy From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, September 18, 2012 1:12 PM To: Sanford Friedenthal; 'CUCCURU Arnaud'; 'BERNARD, Yves' Cc: nerijus@nomagic.com; 'Burkhart Roger M'; 'Bock, Conrad'; 'Ed Seidewitz'; semanticsofcomposites@omg.org Subject: Re: Summary of the Initial submitters meeting at Jacksonville Sandy, I defined AB according to the SysML modeling conventions; that is, the association-owned end, AB::a, is semantically derived as the inverse of the class-owned end, A::b So technically, I should have shown AB::/a instead of AB::a but this would add unnecessary distraction to the main point. The main point is that the semantics of a particular connector . e.g., U::x . is subtly tied to the context of a structured classifier. For example, in the context of U, U::x means that U::partA is connected to U::partB according to the association AB In the context of V, U::x (which is an inherited feature for V) means that U::partA is connected to V::partD according to the association AB In the context of W, U::x (which is an inherited feature for W) means that W::partC is connected to U::partB according to the association AB This is particularly important to clarify this in the spec so that UML/SysML tool vendors implement the right support for UML's structure diagrams and SysML's IBDs. In fact, I would be surprised if there is any UML/SysML tool out there that supports this subtle combinations of connector & redefinition semantics. Nicolas. From: Sanford Friedenthal Date: Tuesday, September 18, 2012 9:53 AM To: JPL , 'CUCCURU Arnaud' , "BERNARD, Yves" Cc: Nerijus Jankevicius , Burkhart Roger M , Conrad Bock , Ed Seidewitz , "semanticsofcomposites@omg.org" Subject: RE: Summary of the Initial submitters meeting at Jacksonville Should the association AB be two way navigable instead of one way? I would agree with your interpretation of how you redefine the inherited connector x:AB. Sandy From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, September 18, 2012 12:26 PM To: CUCCURU Arnaud; BERNARD, Yves; Sanford Friedenthal Cc: nerijus@nomagic.com; 'Burkhart Roger M'; 'Bock, Conrad'; 'Ed Seidewitz'; semanticsofcomposites@omg.org Subject: Re: Summary of the Initial submitters meeting at Jacksonville System engineers at JPL are asking questions about the semantics of connectors when redefinitions are involved. There are many cases: connectors between parts vs. ports vs. combinations of both Connectors typed by associations or not Redefinitions of connected parts vs. redefinitions of parts with connected ports vs. redefinition of connected ports vs redefinition of parts with redefined connected ports In these combinations, the question is whether we have to redefine a connector or not. The spec is not clear on this. The simplest example is where we have a connector among parts (or ports) and some parts (or ports) are redefined but not the connector itself. The attached diagram shows a class U with 2 connected parts. Class V and W specialize U and redefines only one of the connected parts. There is no connector redefinition; but V and W inherit U's connector. The question then is what is the semantics of the inherited connector in the specialized classes? I believe that the meaning of the inherited connector should be that of connecting the redefining parts (instead of the inherited, redefined parts as done in the parent class U). I've attached a diagram to illustrate this problem. Comments? - Nicolas