Issue 7364: section on connectors in the component chapter (uml2-rtf) Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu) Nature: Clarification Severity: Critical Summary: The section on connectors in the component chapter does not add any new functionality to the connectors defined in internal structure. It does provide an additional notation for assembly connectors. There is no reason to have this section in components. Everything that is said semantically about connectors here applies equally to the more general connector. Suggestion: Do not subtype connector in component but move the content of this section to the connector section in internal structure and merge with the section there. Adjust the examples to apply to structured classifiers in general (i.e., delete the component symbol). Further, the ConnectorKind should be derived as it is determined by the manner in which the connector is attached to connectable elements. Deriving this connector ensures that constraints are always true and allows to do away with some consistency constraints. (Actually, it is not clear what the value of this attribute is, as it is already determined from the attachments.) Alternatively, if the presentation option is not in general desired (albeit I cannot see why this additional consistency would not be wanted), the text can be moved up but the presentation option can be added in this section. Resolution: Moving all of BasicComponents.Connector into InternalStructures, although perhaps strategically a good idea, seems like a bridge too far for the RTF. Also Thomas is not entirely accurate when he says it adds no new functionality apart from the notation. In particular BasicComponents adds the idea of a connector contract, which is a set of Behaviors. Therefore I propose that we leave the text where it is, albeit we should fix the many bugs in it that are the topics of this and other issues. However the proposal that kind:ConnectorKind should be derived is entirely sensible, especially since the current constraints on connector kind are the topic of numerous issues (7248-7251). Revised Text: Under 8.1, Basic Components, replace the following sentence: "In addition, the BasicComponents package defines specialized connectors for 'wiring' components together based on interface compatibility." by "In addition, the BasicComponents package allows a connector to carry one or more Behaviors that specify the valid interaction patterns across the connector." Under 8.3.3, replace the first sentence: "The connector concept is extended in the Components package to include interface based constraints and notation." by "The connector concept is extended in the Components package to include contracts and notation." In the model (figure 8.3) show /kind: connectorKind as derived. Under 8.3.3 Description, insert the word "derived" before the phrase "connector kind attribute". Under 8.3.3 Connector Attributes, Package BasicComponents, replace: kind : ConnectorKind Indicates the kind of connector. By: /kind : ConnectorKind Indicates the kind of connector. This is derived: a connector with one or more ends connected to a Port which is not on a Part and which is not a behavior port is a delegation; otherwise it is an assembly. context Connector::kind : ConnectorKind derive: if end->exists( e:ConnectorEnd | e.role.oclIsKindOf(Port) and e.partWithPort->isEmpty() and not e.role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif Actions taken: May 19, 2004: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 20 May 2004 12:56:30 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Thomas Weigert Company: Motorola mailFrom: thomas.weigert@motorola.com Notification: No Specification: UML Section: 8.3.2 FormalNumber: ptc/03-08-02 Version: 2.0 RevisionDate: 02/08/2003 Page: 143 Nature: Clarification Severity: Critical HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description The section on connectors in the component chapter does not add any new functionality to the connectors defined in internal structure. It does provide an additional notation for assembly connectors. There is no reason to have this section in components. Everything that is said semantically about connectors here applies equally to the more general connector. Suggestion: Do not subtype connector in component but move the content of this section to the connector section in internal structure and merge with the section there. Adjust the examples to apply to structured classifiers in general (i.e., delete the component symbol). Further, the ConnectorKind should be derived as it is determined by the manner in which the connector is attached to connectable elements. Deriving this connector ensures that constraints are always true and allows to do away with some consistency constraints. (Actually, it is not clear what the value of this attribute is, as it is already determined from the attachments.) Alternatively, if the presentation option is not in general desired (albeit I cannot see why this additional consistency would not be wanted), the text can be moved up but the presentation option can be added in this section. To: uml2-rtf@omg.org Subject: Ballot 6 X-KeepSent: E6F14668:5C2A5379-852575B0:004FEB59; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Fri, 8 May 2009 11:18:49 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 05/08/2009 09:18:51, Serialize complete at 05/08/2009 09:18:51 Issue 7247 through a delegation connector from a Port to contained Parts whose type is a Component or simple Class. --> through a delegation connector from a Port to contained Parts with compatible type. Issue 7349 An Interface isn't a connectable element and therefore cannot be the source or target of a delegation connector. 3] If a delegation connector is defined between a source Interface or Port and a target Interface or Port, then the target Interface must support a signature compatible subset of Operations of the source Interface or Port. --> 3] If a delegation connector is defined between a source ConnectableElement and a target Connectable, then the target ConnectableElement type must support a signature compatible subset of Operations of the source ConnectableElement type. Issue 7364: Under 8.1, I think it is a mistake to apply contract Behaviors to a Connector to determine the valid interaction pattern. It is the ports that should define this so the expected interactions are followed regardless of the specific connector between them. SoaML clarifies this. But the RTF needn't fix this, we can get it in an RFP. Issue 8168: The same ball and socket notation for complex ports or classes should also apply to dependency wires, not just connectors. The should be treated exactly the same. Figure 8.12 appears wrong. The Delegation connectors are missing arrow heads, and the one from Account appears to be connected to the socket instead of the port. I don't recall any ball and socket notation for delegation connectors, since there's only one ball or one socket. Issue 8705 This section in the spec is confusing realization with composite structure. Figure 8.10 uses realization to indicate what Customer needs to be implemented. This should be shown with either usage dependencies or parts in the composite structure of Customer. Realization should mean that the realizing classifier provides an implementation of all the features of the realized classifier - often an Interface or <> Component, with perhaps some additional features required to do so. We should not mix realization and composite structure or usage dependencies. This creates enormous confusion for components and results in poor realization semantics. Issue 8900 Figure 8.15 should include the classifier the composite structure is contained in. Otherwise this diagram is not a valid diagram and results in confusion between class-level dependency wiring (where a package is the container) and instance level connector wiring. Issue 9464 ..A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the internal realization of that behavior by the component..s parts. It represents the forwarding of signals (operation requests and events): a signal that arrives at a port that has a delegation connector to one or more parts or ports on parts will be passed on to those targets for handling. --> ..A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the internal realization of that behavior by the component..s parts. It represents the forwarding of events (operation requests and events): a signal that arrives at a port that has a delegation connector to one or more parts or ports on parts will be passed on to those targets for handling. A signal isn't an event, signals are carried on SignalEvents. Issue 12985, 13146 Is also confusing realization with composite structure similar to 8705. A component should not provide an interface of its realizing class. This allows a realizing class to have interfaces needed for the realization, but not exposed to the component being realized. Having /provided be derived from the realizingClassifiers seems to turn realization upside down. This completely breaks the relationship between <> Component and <>Component. A realizing classifier should be expected to provide all the structure and behavior of the <> components it realizes, and perhaps have additional structure and behavior necessary for its particular means of realizing that specification. Composite structure and usage dependencies should be completely independent of the concept of realization. Issue 12833 Needs to be updated to include the OCL for allApplicableStereotyes query operation. Ed? Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 Subject: issue 7364 - section on connectors in the component chapter To: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Adam Neal Date: Tue, 19 May 2009 19:29:30 -0400 X-MIMETrack: Serialize by Router on D25ML02/25/M/IBM(Release 8.0.1|February 07, 2008) at 05/19/2009 19:38:50 Hi, Sorry for bringing this up so late in the game, but I just noticed it. I agree with making the connector kind derived. Though the proposed rule also needs to include that the port has behavior=false; the proposal was: "derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty()) then delegation else assembly endif" Consider the same diagram that I used before. Here ports r1 and r2 are both behavior=false. The ports b1 and b2 have behavior=true. Both connectors have ends with partWithPort.isEmpty()=true. The connector between r1 and r2 is a delegation connector. Neither port can initiate a signal nor can they terminate one (since behavior=false), thus the connector must be a delegate. The connector between b1 and b2 is assembly, as both ports can initiate and terminate the signals (behavior=true). The OCL that was provided forces the connector between b1 and b2 to be delegate which is not correct. Therefore, we need to add the check for behavior into the OCL: derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty() and e.role.oclAsType(Port).isBehavior=false) then delegation else assembly endif Regards, Adam From: Steve Cook To: Adam Neal , "uml2-rtf@omg.org" Date: Wed, 20 May 2009 10:57:17 +0100 Subject: RE: issue 7364 - section on connectors in the component chapter Thread-Topic: issue 7364 - section on connectors in the component chapter Thread-Index: AcnY2y2iEY2nEVZtQCa1+OWKEy1scgAU43qg Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Adam, that.s a good catch. I don.t really know how we deal with this procedurally because we are half way through voting on the final ballot. Personally I would be perfectly happy for this to be treated simply as a typo if nobody objects. Thanks -- Steve From: Adam Neal [mailto:Adam_Neal@ca.ibm.com] Sent: 20 May 2009 00:30 To: uml2-rtf@omg.org Subject: issue 7364 - section on connectors in the component chapter Hi, Sorry for bringing this up so late in the game, but I just noticed it. I agree with making the connector kind derived. Though the proposed rule also needs to include that the port has behavior=false; the proposal was: "derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty()) then delegation else assembly endif" Consider the same diagram that I used before. Here ports r1 and r2 are both behavior=false. The ports b1 and b2 have behavior=true. Both connectors have ends with partWithPort.isEmpty()=true. The connector between r1 and r2 is a delegation connector. Neither port can initiate a signal nor can they terminate one (since behavior=false), thus the connector must be a delegate. The connector between b1 and b2 is assembly, as both ports can initiate and terminate the signals (behavior=true). The OCL that was provided forces the connector between b1 and b2 to be delegate which is not correct. Therefore, we need to add the check for behavior into the OCL: derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty() and e.role.oclAsType(Port).isBehavior=false) then delegation else assembly endif Regards, Adam From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Date: Wed, 20 May 2009 16:03:14 +0100 Subject: RE: issue 7364 - section on connectors in the component chapter Thread-Topic: issue 7364 - section on connectors in the component chapter Thread-Index: AcnZUvguV3Vm1cGKTqGOKJqlBXrKhQACQySw Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Maged, how would you prefer I handle this? -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 20 May 2009 14:57 To: Steve Cook Cc: Adam Neal; uml2-rtf@omg.org Subject: Re: issue 7364 - section on connectors in the component chapter Another possibility is to withdraw the proposal prior to closing of the ballot (it's been done before) and then resubmit it for the next one. I believe that you still have more ballots due. Bran On Wed, May 20, 2009 at 5:57 AM, Steve Cook wrote: Adam, that.s a good catch. I don.t really know how we deal with this procedurally because we are half way through voting on the final ballot. Personally I would be perfectly happy for this to be treated simply as a typo if nobody objects. Thanks -- Steve From: Adam Neal [mailto:Adam_Neal@ca.ibm.com] Sent: 20 May 2009 00:30 To: uml2-rtf@omg.org Subject: issue 7364 - section on connectors in the component chapter Hi, Sorry for bringing this up so late in the game, but I just noticed it. I agree with making the connector kind derived. Though the proposed rule also needs to include that the port has behavior=false; the proposal was: "derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty()) then delegation else assembly endif" Consider the same diagram that I used before. Here ports r1 and r2 are both behavior=false. The ports b1 and b2 have behavior=true. Both connectors have ends with partWithPort.isEmpty()=true. The connector between r1 and r2 is a delegation connector. Neither port can initiate a signal nor can they terminate one (since behavior=false), thus the connector must be a delegate. The connector between b1 and b2 is assembly, as both ports can initiate and terminate the signals (behavior=true). The OCL that was provided forces the connector between b1 and b2 to be delegate which is not correct. Therefore, we need to add the check for behavior into the OCL: derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty() and e.role.oclAsType(Port).isBehavior=false) then delegation else assembly endif Regards, Adam Subject: RE: issue 7364 - section on connectors in the component chapter To: Steve Cook Cc: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 20 May 2009 12:51:49 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 05/20/2009 12:51:49 Since this is not strictly editorial, I will remove it and resubmit in ballot 7. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 05/20/2009 11:03 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: issue 7364 - section on connectors in the component chapter Maged, how would you prefer I handle this? -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 20 May 2009 14:57 To: Steve Cook Cc: Adam Neal; uml2-rtf@omg.org Subject: Re: issue 7364 - section on connectors in the component chapter Another possibility is to withdraw the proposal prior to closing of the ballot (it's been done before) and then resubmit it for the next one. I believe that you still have more ballots due. Bran On Wed, May 20, 2009 at 5:57 AM, Steve Cook wrote: Adam, that.s a good catch. I don.t really know how we deal with this procedurally because we are half way through voting on the final ballot. Personally I would be perfectly happy for this to be treated simply as a typo if nobody objects. Thanks -- Steve From: Adam Neal [mailto:Adam_Neal@ca.ibm.com] Sent: 20 May 2009 00:30 To: uml2-rtf@omg.org Subject: issue 7364 - section on connectors in the component chapter Hi, Sorry for bringing this up so late in the game, but I just noticed it. I agree with making the connector kind derived. Though the proposed rule also needs to include that the port has behavior=false; the proposal was: "derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty()) then delegation else assembly endif" Consider the same diagram that I used before. Here ports r1 and r2 are both behavior=false. The ports b1 and b2 have behavior=true. Both connectors have ends with partWithPort.isEmpty()=true. The connector between r1 and r2 is a delegation connector. Neither port can initiate a signal nor can they terminate one (since behavior=false), thus the connector must be a delegate. The connector between b1 and b2 is assembly, as both ports can initiate and terminate the signals (behavior=true). The OCL that was provided forces the connector between b1 and b2 to be delegate which is not correct. Therefore, we need to add the check for behavior into the OCL: derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty() and e.role.oclAsType(Port).isBehavior=false) then delegation else assembly endif Regards, Adam pic31388.gif From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Date: Thu, 21 May 2009 09:22:24 +0100 Subject: RE: issue 7364 - section on connectors in the component chapter Thread-Topic: issue 7364 - section on connectors in the component chapter Thread-Index: AcnZa/ZZ0NKje86NQ6uaiwCu8/6leAAgUq4g Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Maged Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 May 2009 17:52 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: issue 7364 - section on connectors in the component chapter Since this is not strictly editorial, I will remove it and resubmit in ballot 7. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 05/20/2009 11:03 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: issue 7364 - section on connectors in the component chapter Maged, how would you prefer I handle this? -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 20 May 2009 14:57 To: Steve Cook Cc: Adam Neal; uml2-rtf@omg.org Subject: Re: issue 7364 - section on connectors in the component chapter Another possibility is to withdraw the proposal prior to closing of the ballot (it's been done before) and then resubmit it for the next one. I believe that you still have more ballots due. Bran On Wed, May 20, 2009 at 5:57 AM, Steve Cook wrote: Adam, that.s a good catch. I don.t really know how we deal with this procedurally because we are half way through voting on the final ballot. Personally I would be perfectly happy for this to be treated simply as a typo if nobody objects. Thanks -- Steve From: Adam Neal [mailto:Adam_Neal@ca.ibm.com] Sent: 20 May 2009 00:30 To: uml2-rtf@omg.org Subject: issue 7364 - section on connectors in the component chapter Hi, Sorry for bringing this up so late in the game, but I just noticed it. I agree with making the connector kind derived. Though the proposed rule also needs to include that the port has behavior=false; the proposal was: "derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty()) then delegation else assembly endif" Consider the same diagram that I used before. Here ports r1 and r2 are both behavior=false. The ports b1 and b2 have behavior=true. Both connectors have ends with partWithPort.isEmpty()=true. The connector between r1 and r2 is a delegation connector. Neither port can initiate a signal nor can they terminate one (since behavior=false), thus the connector must be a delegate. The connector between b1 and b2 is assembly, as both ports can initiate and terminate the signals (behavior=true). The OCL that was provided forces the connector between b1 and b2 to be delegate which is not correct. Therefore, we need to add the check for behavior into the OCL: derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty() and e.role.oclAsType(Port).isBehavior=false) then delegation else assembly endif Regards, Adam To: uml2-rtf@omg.org Subject: Review of Ballot 6 X-KeepSent: B2E56A1E:CA4ACA57-852575BE:00549D44; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Wed, 27 May 2009 15:09:53 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 05/27/2009 13:09:56, Serialize complete at 05/27/2009 13:09:56 Sorry about taking so long on reviewing ballot 6. There just isn't enough time for everything. 6433 I think the resolution is confusing dependency wires between interfaces/usages/realizations and connectors between connectable elements. Dependency wires, whether they're shown with dependency or ball and socket notation should be between types that can be used to define connectable elements. This way the structural wiring shown at the class level using dependencies is consistent with the structural wiring using connectors at the part level. It seems very strange to create a dependency between a usage and realization in order to effect ball and socket notation. It makes no sense to individually connect different interfaces of the same component or port as at the part or runtime level, the connections are never between the individual interfaces, they're always between the parts that provide and use the interfaces. The ball and socket notation should simply be a notation shorthand for dependency wires or connectors where the connection between the classes or parts only involves a single provided and required interface. This is consistent with the intent in the current spec and with the semantics of connection. We shouldn't confuse notation options and conveniences with different elements in the metaclass. Figure 8.15 should show the dependency wires connected to the ports, not the ball and socket representing the provided and required interfaces. If the dependency is between the usage and realization of the classes used to type the ports, then this implies a dependency between all usages of those classes, not the particular usages to define individual ports. This seems like unintended coupling. This also appears inconsistent with the resolution for 9464. 7364 There was another issue raised suggesting that the contract for a connector should be a classifier rather than just a behavior. This would for example allow a collaboration to be used to define the contract allowing collaboration role bindings to indicate what parts play what roles in a multi-party contract. The current use of a behavior is not adequate because there is no context in which to connect the ends of the connector to representing lifelines, partitions or call operation action target input pins. So the contract is not very useful. SoaML did not use connector contract because the protocol for interaction between ports should be defined by the ports, not the connector. This ensures different instances of participants follow the correct protocol, regardless of the particular connector that connects them. Service contracts in SoaML also bind the ports to the protocols specified by their roles in the contract. This is still not associated with the connector contract. But perhaps this should be raised as a new issue and not change the resolution of this one. 8160 The connectors should never be to the balls or sockets - but rather to the ports or parts that provide or require the interfaces. The ball and socket is a notation for a derived provided or required interface, not a connectable element. This makes the ball and socket notation even more confusing. Figure 8.12, the delegation connectors are missing arrows and should be to/from the ports, not the balls and sockets. This also has significant implications for current tools which would have to special case connectable elements and ball and socket interface notation. 8705 This resolution does not sufficiently define what ComponentRealization means. ComponentRealizaiton should not be confused with usage dependencies or parts in a components internal structure. In figure 8.10, CustomerImpl, CustomerColl and CustomerDef are components used by Customer for its implementation, they don't realize the implementation. One would expect parts typed by these classes to be in the internal structure of Customer, perhaps with a delegation connector to the part typed by CustomerImpl The idea of ComponentRealization should be similar to InterfaceRealization. A realizing component must at least have all the ports and provide and use all the interfaces of the <> components it realizes, and must provide implementing methods that are behaviorally consistent with the behaviors of the realized specification components. This is clarified in SoaML to distinguish specification participants that can be used to define the architecture of a participant from realizing participant that can be instantiated in some execution environment. 8900 Figure 8.17 and 8.18 are not valid UML diagrams. The right part of the figure is missing a context in which these parts are connected. This results in continued confusion between class and instance level modeling and should be avoided. Correcting this could be considered an editorial change by simply adding a containing component. 12985, 13146 I don't agree with the resolution. See comments on 8705. A realizing classifier realizes its specification components, not the other way around. So the realizing classifier must realize and use all of the interfaces of its specification component, but may have more. The specification component would never provide or use interfaces of its realizing classifier because 1) it can't be instantiated and 2) this would be the opposite of what is desired for decoupling component specification from many possibly quite different component realizations. The interfaces a component exposes are those it realizes directly or indirectly through its ports. The interfaces realized by its realizing classifiers must be a superset of this, but don't contribute additional interfaces. Suggest pulling 8705, 12985 and 13146 until we can get clarification on the meaning of ComponentRealization and <> Component. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Rouquette, Nicolas F" To: "uml2-rtf@omg.org" Date: Mon, 1 Jun 2009 20:31:46 -0700 Subject: Ballot7: resolution for 7364 needs clarification Thread-Topic: Ballot7: resolution for 7364 needs clarification Thread-Index: AcnjMqfy3H6bqB9HTvuHOzdqss6NiA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized The proposed resolution makes Connector::kind a derived property: /kind : ConnectorKind Indicates the kind of connector. This is derived: a connector that connects only parts or Ports on parts has kind =assembly; otherwise it has kind =delegation. context Connector::kind : ConnectorKind derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty()) and e.role.oclAsType(Port).isBehavior=false) then delegation else assembly endif First, the above OCL expression is syntactically invalid; this can be easily fixed as shown below: context Connector::kind : ConnectorKind derive: if end->one(e:ConnectorEnd|e.role.oclIsKindOf(Port) and e.partWithPort->isEmpty() and not e.role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif Second, the relationship between the English description of the derivation rule and the (corrected) OCL constraint needs to be explained. How does .a connector that connects only parts or Ports on parts. become .if end->one(..). in OCL? How are .Ports on parts. translated in OCL? It isn.t clear to me whether the derivation rule above and the corresponding OCL are meant to take advantage of any constraints on Connector in 8.3.3 and 9.3.6. - Nicolas. From: Steve Cook To: "Rouquette, Nicolas F" , "uml2-rtf@omg.org" CC: Adam Neal Date: Tue, 2 Jun 2009 10:55:48 +0100 Subject: RE: Ballot7: resolution for 7364 needs clarification Thread-Topic: Ballot7: resolution for 7364 needs clarification Thread-Index: AcnjMqfy3H6bqB9HTvuHOzdqss6NiAAMYO1Q Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Nicolas Good points. On closer inspection I realize it is still wrong. I am referring back to Adam.s earlier comment: ***** Consider the same diagram that I used before. Here ports r1 and r2 are both behavior=false. The ports b1 and b2 have behavior=true. Both connectors have ends with partWithPort.isEmpty()=true. The connector between r1 and r2 is a delegation connector. Neither port can initiate a signal nor can they terminate one (since behavior=false), thus the connector must be a delegate. The connector between b1 and b2 is assembly, as both ports can initiate and terminate the signals (behavior=true). The OCL that was provided forces the connector between b1 and b2 to be delegate which is not correct. ***** I have now modified it as follows: /kind : ConnectorKind Indicates the kind of connector. This is derived: a connector with one or more ends connected to a Port which is not on a Part and which is not a behavior port is a delegation; otherwise it is an assembly. context Connector::kind : ConnectorKind derive: if end->exists( e:ConnectorEnd | e.role.oclIsKindOf(Port) and e.partWithPort->isEmpty() and not e.role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif I have revised the resolution and dropped it into Ballot 8 drafts. With regard to >It isn.t clear to me whether the derivation rule above and the corresponding OCL are meant to take advantage of any constraints on Connector in 8.3.3 and 9.3.6. Those constraints are subject to separate resolutions and do not currently have OCL formulations. But I believe that the derivation is not related to the compatibility rules that you refer to. I.e. it can be decided whether a connector is assembly or delegation independently of whether it connects compatible elements. Thanks -- Steve From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 02 June 2009 04:32 To: uml2-rtf@omg.org Subject: Ballot7: resolution for 7364 needs clarification The proposed resolution makes Connector::kind a derived property: /kind : ConnectorKind Indicates the kind of connector. This is derived: a connector that connects only parts or Ports on parts has kind =assembly; otherwise it has kind =delegation. context Connector::kind : ConnectorKind derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty()) and e.role.oclAsType(Port).isBehavior=false) then delegation else assembly endif First, the above OCL expression is syntactically invalid; this can be easily fixed as shown below: context Connector::kind : ConnectorKind derive: if end->one(e:ConnectorEnd|e.role.oclIsKindOf(Port) and e.partWithPort->isEmpty() and not e.role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif Second, the relationship between the English description of the derivation rule and the (corrected) OCL constraint needs to be explained. How does .a connector that connects only parts or Ports on parts. become .if end->one(..). in OCL? How are .Ports on parts. translated in OCL? It isn.t clear to me whether the derivation rule above and the corresponding OCL are meant to take advantage of any constraints on Connector in 8.3.3 and 9.3.6. - Nicolas. From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Date: Tue, 2 Jun 2009 10:59:24 +0100 Subject: RE: Ballot7: resolution for 7364 needs clarification Thread-Topic: Ballot7: resolution for 7364 needs clarification Thread-Index: AcnjMqfy3H6bqB9HTvuHOzdqss6NiAAMYO1QAAEes9A= Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Maged Please withdraw 7364 from ballot 7 and add it to ballot 8. Thanks -- Steve From: Steve Cook Sent: 02 June 2009 10:56 To: 'Rouquette, Nicolas F'; uml2-rtf@omg.org Cc: 'Adam Neal' Subject: RE: Ballot7: resolution for 7364 needs clarification Nicolas Good points. On closer inspection I realize it is still wrong. I am referring back to Adam.s earlier comment: ***** Consider the same diagram that I used before. Here ports r1 and r2 are both behavior=false. The ports b1 and b2 have behavior=true. Both connectors have ends with partWithPort.isEmpty()=true. The connector between r1 and r2 is a delegation connector. Neither port can initiate a signal nor can they terminate one (since behavior=false), thus the connector must be a delegate. The connector between b1 and b2 is assembly, as both ports can initiate and terminate the signals (behavior=true). The OCL that was provided forces the connector between b1 and b2 to be delegate which is not correct. ***** I have now modified it as follows: /kind : ConnectorKind Indicates the kind of connector. This is derived: a connector with one or more ends connected to a Port which is not on a Part and which is not a behavior port is a delegation; otherwise it is an assembly. context Connector::kind : ConnectorKind derive: if end->exists( e:ConnectorEnd | e.role.oclIsKindOf(Port) and e.partWithPort->isEmpty() and not e.role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif I have revised the resolution and dropped it into Ballot 8 drafts. With regard to >It isn.t clear to me whether the derivation rule above and the corresponding OCL are meant to take advantage of any constraints on Connector in 8.3.3 and 9.3.6. Those constraints are subject to separate resolutions and do not currently have OCL formulations. But I believe that the derivation is not related to the compatibility rules that you refer to. I.e. it can be decided whether a connector is assembly or delegation independently of whether it connects compatible elements. Thanks -- Steve From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 02 June 2009 04:32 To: uml2-rtf@omg.org Subject: Ballot7: resolution for 7364 needs clarification The proposed resolution makes Connector::kind a derived property: /kind : ConnectorKind Indicates the kind of connector. This is derived: a connector that connects only parts or Ports on parts has kind =assembly; otherwise it has kind =delegation. context Connector::kind : ConnectorKind derive: if end->one( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty()) and e.role.oclAsType(Port).isBehavior=false) then delegation else assembly endif First, the above OCL expression is syntactically invalid; this can be easily fixed as shown below: context Connector::kind : ConnectorKind derive: if end->one(e:ConnectorEnd|e.role.oclIsKindOf(Port) and e.partWithPort->isEmpty() and not e.role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif Second, the relationship between the English description of the derivation rule and the (corrected) OCL constraint needs to be explained. How does .a connector that connects only parts or Ports on parts. become .if end->one(..). in OCL? How are .Ports on parts. translated in OCL? It isn.t clear to me whether the derivation rule above and the corresponding OCL are meant to take advantage of any constraints on Connector in 8.3.3 and 9.3.6. - Nicolas. Subject: resolution 7364 from ballot 8 (Components) To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 16 Jul 2009 22:20:39 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/16/2009 22:20:30 The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: Re: resolution 7364 from ballot 8 (Components) To: Maged Elaasar Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 16 Jul 2009 22:38:16 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/16/2009 22:38:12 Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic19272.gif From: Steve Cook To: Maged Elaasar , "uml2-rtf@omg.org" Date: Fri, 17 Jul 2009 10:26:50 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoGhawiAlKD0sFyQqSjbajZRvqjOAAOoKCA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US It.s not shown as [0..1] in chapter 8 text or diagrams. I suppose for minimum impact, yes we should make it [1] in the model too. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:21 To: uml2-rtf@omg.org Subject: resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Date: Fri, 17 Jul 2009 10:30:43 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoGh+udR6gjdB9VTgyIXUOK+LcCkwAOO0pQ Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: resolution 7364 from ballot 8 (Components) To: Steve Cook Cc: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 17 Jul 2009 10:22:47 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/17/2009 10:22:54 Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic19140.gif From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Date: Fri, 17 Jul 2009 15:38:02 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoG6pQuwtfCflFsTYSZO0pd6UncpgAACUXw Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 To: "uml2-rtf@omg.org" Subject: RE: resolution 7364 from ballot 8 (Components) X-KeepSent: D6784DB1:C810D3A9-852575F6:00519B72; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Fri, 17 Jul 2009 11:07:15 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 07/17/2009 09:07:17, Serialize complete at 07/17/2009 09:07:17 Steve, You're right. Merges that are defined on the packages themselves define what is in the package, and is independent of merges creating the compliance levels. That is, all uses of a package will always include everything it is defined to merge. However, there are a historical and practical reasons we didn't exploit this during the development of the UML2 spec. The historical reason is that we were implementing package merge as it was being defined and used to create the UML2 spec. So it wasn't available to do the merges. That isn't true now, and it raises the question about what the XMI should be for these packages - the model as described using the merges, or the merged content for the package. Of course either is OK since they are semantically equivalent. The latter is more literal in terms of matching the XMI with the spec, but less useful. The other reason we didn't make use of these intermediate merges is that in order for the merge to be valid, there couldn't be any undefined references in the source or target packages. This is because it would be impossible to apply the matching rules on these elements because we wouldn't know what they are. So as a practical matter, we copied into the merge source package the elements needed to resolve any references so the merge could be well-defined. I realize this is not ideal and we should certainly address this issue in future UML work. It should be very easy to factor UML into different modeling capabilities that can be easily merged by end users to address their particular viewpoints, views and modeling requirements. There may be some concepts in the semantic web that we could exploit to facilitate this. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Steve Cook To: Maged Elaasar Cc: "uml2-rtf@omg.org" Date: 07/17/2009 10:42 AM Subject: RE: resolution 7364 from ballot 8 (Components) -------------------------------------------------------------------------------- Maged I disagree. You say (in your other email): ..Since the spec sections are documenting things "before" the merge .... Here..s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that ..The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say ..The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says ..a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: resolution 7364 from ballot 8 (Components) To: Steve Cook Cc: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 17 Jul 2009 11:35:47 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/17/2009 11:35:33 Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic00228.gif From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Date: Fri, 17 Jul 2009 17:41:25 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoG9FJ/8WlI48ojSLqUnMIkmbLQ7wACK/Sg Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: resolution 7364 from ballot 8 (Components) To: Steve Cook Cc: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 20 Jul 2009 09:46:58 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/20/2009 09:47:10 Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic07004.gif Subject: RE: resolution 7364 from ballot 8 (Components) To: Maged Elaasar Cc: Steve Cook , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 20 Jul 2009 09:59:33 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/20/2009 09:59:34 Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic26011.gif From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Date: Mon, 20 Jul 2009 15:17:42 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoJQpE4fMGvIvFiR8uiJgrs2E+3LwAAFYAA Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: resolution 7364 from ballot 8 (Components) To: Steve Cook Cc: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 20 Jul 2009 11:08:16 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/20/2009 11:08:07 Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections 4) If we copied down stuff, doesn't this introduce a maintainnce problem? 5) Is this an editorial change? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic17407.gif From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Date: Mon, 20 Jul 2009 16:19:11 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoJTAa6Lk1w3k/sQE6isSZhIOIbvgAACwNA Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Maged My own views on this inline. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 16:08 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? I don.t see any alternative, given the merge conventions we are using. 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort Since there is no way not to have that stuff in the end result because of the merge rules, I don.t see why we would need to include it. 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections That.s a matter of spec convention about which I am no expert. I just think in general that redundancy is bad, so why introduce it? 4) If we copied down stuff, doesn't this introduce a maintainnce problem? Yes: but the problem would not exist if we implemented the package merges properly! The original point of package merge was to remove redundancy, not to add it. 5) Is this an editorial change? I don.t know. Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: resolution 7364 from ballot 8 (Components) To: Steve Cook Cc: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 20 Jul 2009 14:40:29 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/20/2009 14:40:14 Steve, this is the only one I am hesistant to introduce editorial changes for, just because of the amount of "copying down" I have to do in both the metamodel and the spec doc. Also, I am not aware of any other situation where we had to "copy down" featurs, constrants..with their details, , other than introducing similary named Types as merge increments (can someone point me to examples?) The other alternative is to Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 11:19 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged My own views on this inline. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 16:08 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? I don.t see any alternative, given the merge conventions we are using. 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort Since there is no way not to have that stuff in the end result because of the merge rules, I don.t see why we would need to include it. 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections That.s a matter of spec convention about which I am no expert. I just think in general that redundancy is bad, so why introduce it? 4) If we copied down stuff, doesn't this introduce a maintainnce problem? Yes: but the problem would not exist if we implemented the package merges properly! The original point of package merge was to remove redundancy, not to add it. 5) Is this an editorial change? I don.t know. Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic24110.gif Subject: RE: resolution 7364 from ballot 8 (Components) To: Maged Elaasar Cc: Steve Cook , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 20 Jul 2009 14:58:41 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/20/2009 14:58:34 Sorry hit send too fast... The other alternatives are to : 1- opern and issue and had all the changes made and voted on 2- leave the inconsistency for this RTF and resolve it in RTF 2.4 Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 07/20/2009 02:40 PM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, this is the only one I am hesistant to introduce editorial changes for, just because of the amount of "copying down" I have to do in both the metamodel and the spec doc. Also, I am not aware of any other situation where we had to "copy down" featurs, constrants..with their details, , other than introducing similary named Types as merge increments (can someone point me to examples?) The other alternative is to Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 11:19 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged My own views on this inline. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 16:08 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? I don.t see any alternative, given the merge conventions we are using. 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort Since there is no way not to have that stuff in the end result because of the merge rules, I don.t see why we would need to include it. 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections That.s a matter of spec convention about which I am no expert. I just think in general that redundancy is bad, so why introduce it? 4) If we copied down stuff, doesn't this introduce a maintainnce problem? Yes: but the problem would not exist if we implemented the package merges properly! The original point of package merge was to remove redundancy, not to add it. 5) Is this an editorial change? I don.t know. Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic02462.gif From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Date: Mon, 20 Jul 2009 21:19:53 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoJaZpZr3xnJ1y8RaaRA5lsSkEnjQADcWGg Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US I suggest that tomorrow I formulate a revised resolution for 7364 and put it into ballot 9 for a vote. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 19:40 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is the only one I am hesistant to introduce editorial changes for, just because of the amount of "copying down" I have to do in both the metamodel and the spec doc. Also, I am not aware of any other situation where we had to "copy down" featurs, constrants..with their details, , other than introducing similary named Types as merge increments (can someone point me to examples?) The other alternative is to Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 11:19 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged My own views on this inline. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 16:08 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? I don.t see any alternative, given the merge conventions we are using. 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort Since there is no way not to have that stuff in the end result because of the merge rules, I don.t see why we would need to include it. 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections That.s a matter of spec convention about which I am no expert. I just think in general that redundancy is bad, so why introduce it? 4) If we copied down stuff, doesn't this introduce a maintainnce problem? Yes: but the problem would not exist if we implemented the package merges properly! The original point of package merge was to remove redundancy, not to add it. 5) Is this an editorial change? I don.t know. Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: resolution 7364 from ballot 8 (Components) Date: Mon, 20 Jul 2009 16:50:20 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: resolution 7364 from ballot 8 (Components) thread-index: AcoJaZpZr3xnJ1y8RaaRA5lsSkEnjQADcWGgAAEPI1A= From: "Ed Seidewitz" To: "Steve Cook" Cc: Steve . Would it be better to submit a new issue and make the resolution for that, since, technically, we have already resolved 7364? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, July 20, 2009 4:20 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) I suggest that tomorrow I formulate a revised resolution for 7364 and put it into ballot 9 for a vote. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 19:40 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is the only one I am hesistant to introduce editorial changes for, just because of the amount of "copying down" I have to do in both the metamodel and the spec doc. Also, I am not aware of any other situation where we had to "copy down" featurs, constrants..with their details, , other than introducing similary named Types as merge increments (can someone point me to examples?) The other alternative is to Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 11:19 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged My own views on this inline. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 16:08 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? I don.t see any alternative, given the merge conventions we are using. 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort Since there is no way not to have that stuff in the end result because of the merge rules, I don.t see why we would need to include it. 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections That.s a matter of spec convention about which I am no expert. I just think in general that redundancy is bad, so why introduce it? 4) If we copied down stuff, doesn't this introduce a maintainnce problem? Yes: but the problem would not exist if we implemented the package merges properly! The original point of package merge was to remove redundancy, not to add it. 5) Is this an editorial change? I don.t know. Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 From: "Rouquette, Nicolas F (316A)" To: Ed Seidewitz , Steve Cook CC: "uml2-rtf@omg.org" Date: Mon, 20 Jul 2009 14:08:00 -0700 Subject: Re: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoJaZpZr3xnJ1y8RaaRA5lsSkEnjQADcWGgAAEPI1AAAKNE2g== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized I consider copying classes/features an editorial change because the resulting package will have the copied classes/features anyway. It is however unfortunate that we didn.t catch this in the ballot review. - Nicolas. On 7/20/09 1:50 PM, "Ed Seidewitz" wrote: Steve . Would it be better to submit a new issue and make the resolution for that, since, technically, we have already resolved 7364? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, July 20, 2009 4:20 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) I suggest that tomorrow I formulate a revised resolution for 7364 and put it into ballot 9 for a vote. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 19:40 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is the only one I am hesistant to introduce editorial changes for, just because of the amount of "copying down" I have to do in both the metamodel and the spec doc. Also, I am not aware of any other situation where we had to "copy down" featurs, constrants..with their details, , other than introducing similary named Types as merge increments (can someone point me to examples?) The other alternative is to Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 11:19 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged My own views on this inline. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 16:08 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? I don.t see any alternative, given the merge conventions we are using. 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort Since there is no way not to have that stuff in the end result because of the merge rules, I don.t see why we would need to include it. 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections That.s a matter of spec convention about which I am no expert. I just think in general that redundancy is bad, so why introduce it? 4) If we copied down stuff, doesn't this introduce a maintainnce problem? Yes: but the problem would not exist if we implemented the package merges properly! The original point of package merge was to remove redundancy, not to add it. 5) Is this an editorial change? I don.t know. Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com ] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com ] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi . - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com ] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com ] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: resolution 7364 from ballot 8 (Components) To: Steve Cook Cc: Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Tue, 21 Jul 2009 12:12:35 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/21/2009 12:12:37 Steve, I just want us to answer some questions first before we take action: The problem The issue we are talkig about proposes converting BasicComponents::Connector::kind from a non-derived to a derived attribute. The proposed derivation relies on features of Connector that are only available in CompositeStructure subclauses and not in Components, like connector ends, ports..etc. The current writeup about connector kind is in the components subclause. Solution 1 The voted on resolution suggests putting the derivation of "kind" in components, but since we do not have access to the appropriate features, the suggestion now is to "copy down" things from CompositeStructure to Componnets. - Did we even run into a similar problem and had a similar solution (i.e. introduce a merge increment that "copies down" a class's internal structure)? Can we point to examples? - What is supposed to be copied exactly? are we proposing copying needed attributes, association, along with their operations, constraints..etc ? - This means the metamodel and the spec doc will have exact copies of considerable subclauses, dose that include their related text..etc? (I have not seen repeated description in the spec, aside from the known redundancy between infrastructyre/superstructre, but I might have overlooked things Solution 2 We need to refactor Connector::kind to put it into an appropriate level where it has access to needed features, avoiding the "copy down". - Is there a logical place to put in Connector::kind? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook wrote on 07/21/2009 05:09:43 AM: > I am very happy to leave this to as an editorial change if nobody > objects. It doesn.t affect the semantics, and I don.t really know > how to submit a new issue for it . .resolution for 7364 doesn.t > include copying down necessary bits. doesn.t seem a sensible issue > that folks are likely to vote against. > > -- Steve > > From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: 20 July 2009 22:08 > To: Ed Seidewitz; Steve Cook > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > I consider copying classes/features an editorial change because the > resulting package will have the copied classes/features anyway. > It is however unfortunate that we didn.t catch this in the ballot review. > > - Nicolas. > > On 7/20/09 1:50 PM, "Ed Seidewitz" wrote: > Steve . > > Would it be better to submit a new issue and make the resolution for > that, since, technically, we have already resolved 7364? > > -- Ed > > > From: Steve Cook [mailto:Steve.Cook@microsoft.com] > Sent: Monday, July 20, 2009 4:20 PM > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > I suggest that tomorrow I formulate a revised resolution for 7364 > and put it into ballot 9 for a vote. > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com] > Sent: 20 July 2009 19:40 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is the only one I am hesistant to introduce editorial > changes for, just because of the amount of "copying down" I have to > do in both the metamodel and the spec doc. > > Also, I am not aware of any other situation where we had to "copy > down" featurs, constrants..with their details, , other than > introducing similary named Types as merge increments (can someone > point me to examples?) > > The other alternative is to > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 11:19 AM > [image removed] To [image removed] > Maged Elaasar/Ottawa/IBM@IBMCA > [image removed] cc [image removed] > "uml2-rtf@omg.org" > [image removed] Subject [image removed] > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > My own views on this inline. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com] > Sent: 20 July 2009 16:08 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is what I had to copy into BasicComponents to make the > OCL derivation of Connector::kind parse: > > result = > if end->exists( > role.oclIsKindOf(Port) > and partWithPort->isEmpty() > and not role.oclAsType(Port).isBehavior) > then ConnectorKind::delegation > else ConnectorKind::assembly > endif > > [image removed] > > My questions: > > 1) I know we introduced merge increments before by introducing > similarly named Classes, but did we "copy down" attributes, > associations...etc from the original Class? > > I don.t see any alternative, given the merge conventions we > are using. > > 2) If we copied down stuff, did we copy all their constraints, > subsetting...etc? In the set I copied here, there are a bunch of > subsetting, constraints...etc like derivation for > ConnectableElement::end and constraints on ConnectorEnd::partWithPort > > Since there is no way not to have that stuff in the end > result because of the merge rules, I don.t see why we would need to > include it. > > 3) If we copied down stuff, don't we also have to copy down their > subclauses, i.e. in this case introduce 4 new subclauses under 8.3 > with copy down of various sections > > That.s a matter of spec convention about which I am no > expert. I just think in general that redundancy is bad, so why > introduce it? > > 4) If we copied down stuff, doesn't this introduce a maintainnce problem? > > Yes: but the problem would not exist if we implemented the > package merges properly! The original point of package merge was to > remove redundancy, not to add it. > > 5) Is this an editorial change? > > I don.t know. > > > > Thanks, > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 10:17 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > The reason I didn.t suggest moving stuff to chapter 9 in the > original resolution is because (1) it involves significant re- > organization, and (2) a Connector has a .contract. in Components > that it doesn.t have in InternalStructures, and there is text in > chapter 8 that talks about this. I definitely don.t think we could > do all this as an editorial change. > > I think that the copying solution just needs ConnectorEnd and > Property with the partWithPort and ends associations added to figure > 8.3 (assuming the OCL can refer to the type Port without having to > copy that as well). > > -- Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 20 July 2009 15:00 > To: Maged Elaasar > Cc: Steve Cook; uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Actually this might not work as the derivation of 'kind' also refers > to Ports::ConnectorEnd.partwithPort, which would not be avaiable in > InternalStructures. > > My only concern about the copying solution is how much I have to > copy to bring all what is needed for the derivation, and whether > this can pass as editorial change since it could mean introducing > whole new subclases. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM > To > Steve Cook > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Steve, > > Given that Connector::kind's derivation dependency on internal > structures, doesn't it make more sense to move/merge Connector and > ConnectorEnd from BasicComponents to InternalStructures? > > Another reason is that Connector is not referenced by any other > Class in BasicComponents. Look at figures 8.2 and 8.3 > > Opinions? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 12:41 PM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Ok. Given this and Jim.s email it seems that we have a convention > about merges which is different from what I understood. > > With regard to Connector::end, I guess the solution is to copy > ConnectorEnd down into BasicComponents, as well as the containment > relationship. Given the merge semantics, that is a completely neutral change. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 17 July 2009 16:36 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, > > This is not what I understand about the package merge relationships. > > My understanding is that if we have two packages P1 and P2, where P1 > has a package merge to P2, then class P1::C1 does not have direct > access to properties in P2::C1, but it needs to "copy" them in order > to be able to access them. > > This is similar I think to a Class having an InterfaceRealization to > an Interface. The class does not have access to the interface's > properties unless it "copies" them down, i.e. have ones with similarsignature. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 10:38 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I disagree. > > You say (in your other email): .Since the spec sections are > documenting things "before" the merge .... > > Here.s figure 8.1 from the spec (hopefully the email system will > transfer this): > > [image removed] > > This states clearly that PackagingComponents merges BasicComponents, > and so on. This has nothing to do with L1, L2, L3 etc: it is the > normative specification of PackagingComponents. Similarly, > BasicComponents merges StructuredClasses. According to the extensive > explanation in chapter 7, this definitely does mean that the merge > happens here. So it is not true that .The spec suggests that there > is BasicComponents::Connector merges with InternalStructures:: > Connector in some merge level.. These merges are not suggestions > about some merge level, they are definitive (normative) statements > about the definition of these actual packages, and are also > represented in the XMI for UML http://www.omg. > org/spec/UML/20080501/Superstructure.xmi org/spec/UML/20080501/Superstructure.xmi> . > > - -Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 17 July 2009 15:23 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Componnts) > > Steve, The spec suggests that there is BasicComponents::Connector > merges with InternalStructures::Connector in some merge level. It > does not mean that the BasicComponents::Connector class is the > result of this merge, and hence it cannot assume access to features > of that Class. Imagine the case when this class merges with > something else, then the assumption of haing access to the features > of a particular merged_with Class is not valid. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 05:30 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I must be misunderstanding something. > > You say .The property is available in InternalStructures::Connector > but BasicComponents::Connector merges with that class.. > > Section 7.3.40 says .a package merge can be viewed as an operation > that takes the contents of two packages and produces a new package > that combines the contents of the packages involved in the merge. > > How can this not mean that Connector::end is available in > BasicComponents::Connector? > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 17 July 2009 03:38 > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > Another problem with this resolution. The OCL for derivation of > "kind" refers to the "Connector::end" property and gives parse error > as this property is not available in BasicComponents::Connector. > > The property is available in InternalStructures::Connector but > BasicComponents::Connector merges with that class and does not have > a generalization to it (it actually does not have any generalization) > > How do I address this? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM > To > uml2-rtf@omg.org > cc [image removed] > Subject > resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > The resolution is making Connector::kind a derived property. > Currently the metamodel has the multiplicity of this property as > [0..1]. Is this the desired multiplicity after making this property > derived? Wouldn't it be [1]? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 [image removed] From: Steve Cook To: Maged Elaasar CC: Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Date: Tue, 21 Jul 2009 17:44:50 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoKHiMSJlu3I7brRJC5eA6kBVGd4wAABvwQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Maged My answers inline. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 17:13 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, I just want us to answer some questions first before we take action: The problem The issue we are talkig about proposes converting BasicComponents::Connector::kind from a non-derived to a derived attribute. The proposed derivation relies on features of Connector that are only available in CompositeStructure subclauses and not in Components, like connector ends, ports..etc. The current writeup about connector kind is in the components subclause. Solution 1 The voted on resolution suggests putting the derivation of "kind" in components, but since we do not have access to the appropriate features, the suggestion now is to "copy down" things from CompositeStructure to Componnets. Yes: because the semantics of package merge tell us that we really should have access to those things, but because of the way package merge is implemented in the UML spec, they have to be copied - Did we even run into a similar problem and had a similar solution (i.e. introduce a merge increment that "copies down" a class's internal structure)? Can we point to examples? Not many: but look at Classifier on the right hand side of figure 9.2 . it is an exact analogy. Also Classifier in 17.18 copies down the fact that it inherits from Namespace. - What is supposed to be copied exactly? are we proposing copying needed attributes, association, along with their operations, constraints..etc ? We only copy exactly what is needed (you.ve already done that bit). Anything else would get merged later - This means the metamodel and the spec doc will have exact copies of considerable subclauses, dose that include their related text..etc? (I have not seen repeated description in the spec, aside from the known redundancy between infrastructyre/superstructre, but I might have overlooked things I don.t think related text is necessary, by analogy with figures 9.2 and 17.18, where there is none. Solution 2 We need to refactor Connector::kind to put it into an appropriate level where it has access to needed features, avoiding the "copy down". - Is there a logical place to put in Connector::kind? I explicitly decided not to do this in the original resolution, so this could not be an editorial change, and would conflict with the fact that we already voted on the resolution. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook wrote on 07/21/2009 05:09:43 AM: > I am very happy to leave this to as an editorial change if nobody > objects. It doesn.t affect the semantics, and I don.t really know > how to submit a new issue for it . .resolution for 7364 doesn.t > include copying down necessary bits. doesn.t seem a sensible issue > that folks are likely to vote against. > > -- Steve > > From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: 20 July 2009 22:08 > To: Ed Seidewitz; Steve Cook > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > I consider copying classes/features an editorial change because the > resulting package will have the copied classes/features anyway. > It is however unfortunate that we didn.t catch this in the ballot review. > > - Nicolas. > > On 7/20/09 1:50 PM, "Ed Seidewitz" wrote: > Steve . > > Would it be better to submit a new issue and make the resolution for > that, since, technically, we have already resolved 7364? > > -- Ed > > > From: Steve Cook [mailto:Steve.Cook@microsoft.com] > Sent: Monday, July 20, 2009 4:20 PM > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > I suggest that tomorrow I formulate a revised resolution for 7364 > and put it into ballot 9 for a vote. > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com] > Sent: 20 July 2009 19:40 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is the only one I am hesistant to introduce editorial > changes for, just because of the amount of "copying down" I have to > do in both the metamodel and the spec doc. > > Also, I am not aware of any other situation where we had to "copy > down" featurs, constrants..with their details, , other than > introducing similary named Types as merge increments (can someone > point me to examples?) > > The other alternative is to > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 11:19 AM > [image removed] To [image removed] > Maged Elaasar/Ottawa/IBM@IBMCA > [image removed] cc [image removed] > "uml2-rtf@omg.org" > [image removed] Subject [image removed] > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > My own views on this inline. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com] > Sent: 20 July 2009 16:08 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is what I had to copy into BasicComponents to make the > OCL derivation of Connector::kind parse: > > result = > if end->exists( > role.oclIsKindOf(Port) > and partWithPort->isEmpty() > and not role.oclAsType(Port).isBehavior) > then ConnectorKind::delegation > else ConnectorKind::assembly > endif > > [image removed] > > My questions: > > 1) I know we introduced merge increments before by introducing > similarly named Classes, but did we "copy down" attributes, > associations...etc from the original Class? > > I don.t see any alternative, given the merge conventions we > are using. > > 2) If we copied down stuff, did we copy all their constraints, > subsetting...etc? In the set I copied here, there are a bunch of > subsetting, constraints...etc like derivation for > ConnectableElement::end and constraints on ConnectorEnd::partWithPort > > Since there is no way not to have that stuff in the end > result because of the merge rules, I don.t see why we would need to > include it. > > 3) If we copied down stuff, don't we also have to copy down their > subclauses, i.e. in this case introduce 4 new subclauses under 8.3 > with copy down of various sections > > That.s a matter of spec convention about which I am no > expert. I just think in general that redundancy is bad, so why > introduce it? > > 4) If we copied down stuff, doesn't this introduce a maintainnce problem? > > Yes: but the problem would not exist if we implemented the > package merges properly! The original point of package merge was to > remove redundancy, not to add it. > > 5) Is this an editorial change? > > I don.t know. > > > > Thanks, > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 10:17 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > The reason I didn.t suggest moving stuff to chapter 9 in the > original resolution is because (1) it involves significant re- > organization, and (2) a Connector has a .contract. in Components > that it doesn.t have in InternalStructures, and there is text in > chapter 8 that talks about this. I definitely don.t think we could > do all this as an editorial change. > > I think that the copying solution just needs ConnectorEnd and > Property with the partWithPort and ends associations added to figure > 8.3 (assuming the OCL can refer to the type Port without having to > copy that as well). > > -- Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 20 July 2009 15:00 > To: Maged Elaasar > Cc: Steve Cook; uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Actually this might not work as the derivation of 'kind' also refers > to Ports::ConnectorEnd.partwithPort, which would not be avaiable in > InternalStructures. > > My only concern about the copying solution is how much I have to > copy to bring all what is needed for the derivation, and whether > this can pass as editorial change since it could mean introducing > whole new subclases. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM > To > Steve Cook > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Steve, > > Given that Connector::kind's derivation dependency on internal > structures, doesn't it make more sense to move/merge Connector and > ConnectorEnd from BasicComponents to InternalStructures? > > Another reason is that Connector is not referenced by any other > Class in BasicComponents. Look at figures 8.2 and 8.3 > > Opinions? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 12:41 PM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Ok. Given this and Jim.s email it seems that we have a convention > about merges which is different from what I understood. > > With regard to Connector::end, I guess the solution is to copy > ConnectorEnd down into BasicComponents, as well as the containment > relationship. Given the merge semantics, that is a completely neutral change. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 17 July 2009 16:36 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, > > This is not what I understand about the package merge relationships. > > My understanding is that if we have two packages P1 and P2, where P1 > has a package merge to P2, then class P1::C1 does not have direct > access to properties in P2::C1, but it needs to "copy" them in order > to be able to access them. > > This is similar I think to a Class having an InterfaceRealization to > an Interface. The class does not have access to the interface's > properties unless it "copies" them down, i.e. have ones with similarsignature. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 10:38 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I disagree. > > You say (in your other email): .Since the spec sections are > documenting things "before" the merge .... > > Here.s figure 8.1 from the spec (hopefully the email system will > transfer this): > > [image removed] > > This states clearly that PackagingComponents merges BasicComponents, > and so on. This has nothing to do with L1, L2, L3 etc: it is the > normative specification of PackagingComponents. Similarly, > BasicComponents merges StructuredClasses. According to the extensive > explanation in chapter 7, this definitely does mean that the merge > happens here. So it is not true that .The spec suggests that there > is BasicComponents::Connector merges with InternalStructures:: > Connector in some merge level.. These merges are not suggestions > about some merge level, they are definitive (normative) statements > about the definition of these actual packages, and are also > represented in the XMI for UML http://www.omg. > org/spec/UML/20080501/Superstructure.xmi org/spec/UML/20080501/Superstructure.xmi> . > > - -Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 17 July 2009 15:23 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Componnts) > > Steve, The spec suggests that there is BasicComponents::Connector > merges with InternalStructures::Connector in some merge level. It > does not mean that the BasicComponents::Connector class is the > result of this merge, and hence it cannot assume access to features > of that Class. Imagine the case when this class merges with > something else, then the assumption of haing access to the features > of a particular merged_with Class is not valid. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 05:30 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I must be misunderstanding something. > > You say .The property is available in InternalStructures::Connector > but BasicComponents::Connector merges with that class.. > > Section 7.3.40 says .a package merge can be viewed as an operation > that takes the contents of two packages and produces a new package > that combines the contents of the packages involved in the merge. > > How can this not mean that Connector::end is available in > BasicComponents::Connector? > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 17 July 2009 03:38 > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > Another problem with this resolution. The OCL for derivation of > "kind" refers to the "Connector::end" property and gives parse error > as this property is not available in BasicComponents::Connector. > > The property is available in InternalStructures::Connector but > BasicComponents::Connector merges with that class and does not have > a generalization to it (it actually does not have any generalization) > > How do I address this? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM > To > uml2-rtf@omg.org > cc [image removed] > Subject > resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > The resolution is making Connector::kind a derived property. > Currently the metamodel has the multiplicity of this property as > [0..1]. Is this the desired multiplicity after making this property > derived? Wouldn't it be [1]? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 [image removed] Subject: RE: resolution 7364 from ballot 8 (Components) To: Steve Cook Cc: Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Tue, 21 Jul 2009 13:04:28 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/21/2009 13:04:20 Steve, so you are suggesting I do the copying in the metamodel what is enough to make the constraint parse and update Figure 8.3, without copying the corresponding spec text? Wouldn't this leave the metamodel and spec not in sync? I mean it would make the maintaince of this part harder since in the future we have to remember to updat the metamodel part in components based on changes to composite structure. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/21/2009 12:44 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged My answers inline. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 17:13 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, I just want us to answer some questions first before we take action: The problem The issue we are talkig about proposes converting BasicComponents::Connector::kind from a non-derived to a derived attribute. The proposed derivation relies on features of Connector that are only available in CompositeStructure subclauses and not in Components, like connector ends, ports..etc. The current writeup about connector kind is in the components subclause. Solution 1 The voted on resolution suggests putting the derivation of "kind" in components, but since we do not have access to the appropriate features, the suggestion now is to "copy down" things from CompositeStructure to Componnets. Yes: because the semantics of package merge tell us that we really should have access to those things, but because of the way package merge is implemented in the UML spec, they have to be copied - Did we even run into a similar problem and had a similar solution (i.e. introduce a merge increment that "copies down" a class's internal structure)? Can we point to examples? Not many: but look at Classifier on the right hand side of figure 9.2 . it is an exact analogy. Also Classifier in 17.18 copies down the fact that it inherits from Namespace. - What is supposed to be copied exactly? are we proposing copying needed attributes, association, along with their operations, constraints..etc ? We only copy exactly what is needed (you.ve already done that bit). Anything else would get merged later - This means the metamodel and the spec doc will have exact copies of considerable subclauses, dose that include their related text..etc? (I have not seen repeated description in the spec, aside from the known redundancy between infrastructyre/superstructre, but I might have overlooked things I don.t think related text is necessary, by analogy with figures 9.2 and 17.18, where there is none. Solution 2 We need to refactor Connector::kind to put it into an appropriate level where it has access to needed features, avoiding the "copy down". - Is there a logical place to put in Connector::kind? I explicitly decided not to do this in the original resolution, so this could not be an editorial change, and would conflict with the fact that we already voted on the resolution. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook wrote on 07/21/2009 05:09:43 AM: > I am very happy to leave this to as an editorial change if nobody > objects. It doesn.t affect the semantics, and I don.t really know > how to submit a new issue for it . .resolution for 7364 doesn.t > include copying down necessary bits. doesn.t seem a sensible issue > that folks are likely to vote against. > > -- Steve > > From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: 20 July 2009 22:08 > To: Ed Seidewitz; Steve Cook > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > I consider copying classes/features an editorial change because the > resulting package will have the copied classes/features anyway. > It is however unfortunate that we didn.t catch this in the ballot review. > > - Nicolas. > > On 7/20/09 1:50 PM, "Ed Seidewitz" wrote: > Steve . > > Would it be better to submit a new issue and make the resolution for > that, since, technically, we have already resolved 7364? > > -- Ed > > > From: Steve Cook [mailto:Steve.Cook@microsoft.com] > Sent: Monday, July 20, 2009 4:20 PM > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > I suggest that tomorrow I formulate a revised resolution for 7364 > and put it into ballot 9 for a vote. > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com] > Sent: 20 July 2009 19:40 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is the only one I am hesistant to introduce editorial > changes for, just because of the amount of "copying down" I have to > do in both the metamodel and the spec doc. > > Also, I am not aware of any other situation where we had to "copy > down" featurs, constrants..with their details, , other than > introducing similary named Types as merge increments (can someone > point me to examples?) > > The other alternative is to > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 11:19 AM > [image removed] To [image removed] > Maged Elaasar/Ottawa/IBM@IBMCA > [image removed] cc [image removed] > "uml2-rtf@omg.org" > [image removed] Subject [image removed] > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > My own views on this inline. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com] > Sent: 20 July 2009 16:08 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is what I had to copy into BasicComponents to make the > OCL derivation of Connector::kind parse: > > result = > if end->exists( > role.oclIsKindOf(Port) > and partWithPort->isEmpty() > and not role.oclAsType(Port).isBehavior) > then ConnectorKind::delegation > else ConnectorKind::assembly > endif > > [image removed] > > My questions: > > 1) I know we introduced merge increments before by introducing > similarly named Classes, but did we "copy down" attributes, > associations...etc from the original Class? > > I don.t see any alternative, given the merge conventions we > are using. > > 2) If we copied down stuff, did we copy all their constraints, > subsetting...etc? In the set I copied here, there are a bunch of > subsetting, constraints...etc like derivation for > ConnectableElement::end and constraints on ConnectorEnd::partWithPort > > Since there is no way not to have that stuff in the end > result because of the merge rules, I don.t see why we would need to > include it. > > 3) If we copied down stuff, don't we also have to copy down their > subclauses, i.e. in this case introduce 4 new subclauses under 8.3 > with copy down of various sections > > That.s a matter of spec convention about which I am no > expert. I just think in general that redundancy is bad, so why > introduce it? > > 4) If we copied down stuff, doesn't this introduce a maintainnce problem? > > Yes: but the problem would not exist if we implemented the > package merges properly! The original point of package merge was to > remove redundancy, not to add it. > > 5) Is this an editorial change? > > I don.t know. > > > > Thanks, > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 10:17 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > The reason I didn.t suggest moving stuff to chapter 9 in the > original resolution is because (1) it involves significant re- > organization, and (2) a Connector has a .contract. in Components > that it doesn.t have in InternalStructures, and there is text in > chapter 8 that talks about this. I definitely don.t think we could > do all this as an editorial change. > > I think that the copying solution just needs ConnectorEnd and > Property with the partWithPort and ends associations added to figure > 8.3 (assuming the OCL can refer to the type Port without having to > copy that as well). > > -- Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 20 July 2009 15:00 > To: Maged Elaasar > Cc: Steve Cook; uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Actually this might not work as the derivation of 'kind' also refers > to Ports::ConnectorEnd.partwithPort, which would not be avaiable in > InternalStructures. > > My only concern about the copying solution is how much I have to > copy to bring all what is needed for the derivation, and whether > this can pass as editorial change since it could mean introducing > whole new subclases. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM > To > Steve Cook > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Steve, > > Given that Connector::kind's derivation dependency on internal > structures, doesn't it make more sense to move/merge Connector and > ConnectorEnd from BasicComponents to InternalStructures? > > Another reason is that Connector is not referenced by any other > Class in BasicComponents. Look at figures 8.2 and 8.3 > > Opinions? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 12:41 PM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Ok. Given this and Jim.s email it seems that we have a convention > about merges which is different from what I understood. > > With regard to Connector::end, I guess the solution is to copy > ConnectorEnd down into BasicComponents, as well as the containment > relationship. Given the merge semantics, that is a completely neutral change. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 17 July 2009 16:36 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, > > This is not what I understand about the package merge relationships. > > My understanding is that if we have two packages P1 and P2, where P1 > has a package merge to P2, then class P1::C1 does not have direct > access to properties in P2::C1, but it needs to "copy" them in order > to be able to access them. > > This is similar I think to a Class having an InterfaceRealization to > an Interface. The class does not have access to the interface's > properties unless it "copies" them down, i.e. have ones with similarsignature. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 10:38 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I disagree. > > You say (in your other email): .Since the spec sections are > documenting things "before" the merge .... > > Here.s figure 8.1 from the spec (hopefully the email system will > transfer this): > > [image removed] > > This states clearly that PackagingComponents merges BasicComponents, > and so on. This has nothing to do with L1, L2, L3 etc: it is the > normative specification of PackagingComponents. Similarly, > BasicComponents merges StructuredClasses. According to the extensive > explanation in chapter 7, this definitely does mean that the merge > happens here. So it is not true that .The spec suggests that there > is BasicComponents::Connector merges with InternalStructures:: > Connector in some merge level.. These merges are not suggestions > about some merge level, they are definitive (normative) statements > about the definition of these actual packages, and are also > represented in the XMI for UML http://www.omg. > org/spec/UML/20080501/Superstructure.xmi org/spec/UML/20080501/Superstructure.xmi> . > > - -Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 17 July 2009 15:23 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Componnts) > > Steve, The spec suggests that there is BasicComponents::Connector > merges with InternalStructures::Connector in some merge level. It > does not mean that the BasicComponents::Connector class is the > result of this merge, and hence it cannot assume access to features > of that Class. Imagine the case when this class merges with > something else, then the assumption of haing access to the features > of a particular merged_with Class is not valid. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 05:30 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I must be misunderstanding something. > > You say .The property is available in InternalStructures::Connector > but BasicComponents::Connector merges with that class.. > > Section 7.3.40 says .a package merge can be viewed as an operation > that takes the contents of two packages and produces a new package > that combines the contents of the packages involved in the merge. > > How can this not mean that Connector::end is available in > BasicComponents::Connector? > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 17 July 2009 03:38 > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > Another problem with this resolution. The OCL for derivation of > "kind" refers to the "Connector::end" property and gives parse error > as this property is not available in BasicComponents::Connector. > > The property is available in InternalStructures::Connector but > BasicComponents::Connector merges with that class and does not have > a generalization to it (it actually does not have any generalization) > > How do I address this? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM > To > uml2-rtf@omg.org > cc [image removed] > Subject > resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > The resolution is making Connector::kind a derived property. > Currently the metamodel has the multiplicity of this property as > [0..1]. Is this the desired multiplicity after making this property > derived? Wouldn't it be [1]? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 [image removed] pic29606.gif Subject: RE: resolution 7364 from ballot 8 (Components) Date: Tue, 21 Jul 2009 13:14:30 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: resolution 7364 from ballot 8 (Components) thread-index: AcoKJWCMgv1uYN8ZS7yN1tuGROQTggAAHhIw From: "Ed Seidewitz" To: "Maged Elaasar" , "Steve Cook" Cc: "Rouquette, Nicolas F (316A)" , Maged . If you .copy down. a class in the metamodel, then you do need to introduce a corresponding class description for the copied class in whatever subclause it was copied into. This class description should list all the copied attributes and associations. However, it is not necessary to repeat any descriptive text, other than perhaps an introductory sentence. Typically, this is where it is really useful to note in the Generalizations section that this is a merge increment of some other .base. version of the class, and then you can just refer to the subclause of this .base. version in the Semantics section of the copied down class description. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, July 21, 2009 1:04 PM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, so you are suggesting I do the copying in the metamodel what is enough to make the constraint parse and update Figure 8.3, without copying the corresponding spec text? Wouldn't this leave the metamodel and spec not in sync? I mean it would make the maintaince of this part harder since in the future we have to remember to updat the metamodel part in components based on changes to composite structure. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/21/2009 12:44 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged My answers inline. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 17:13 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, I just want us to answer some questions first before we take action: The problem The issue we are talkig about proposes converting BasicComponents::Connector::kind from a non-derived to a derived attribute. The proposed derivation relies on features of Connector that are only available in CompositeStructure subclauses and not in Components, like connector ends, ports..etc. The current writeup about connector kind is in the components subclause. Solution 1 The voted on resolution suggests putting the derivation of "kind" in components, but since we do not have access to the appropriate features, the suggestion now is to "copy down" things from CompositeStructure to Componnets. Yes: because the semantics of package merge tell us that we really should have access to those things, but because of the way package merge is implemented in the UML spec, they have to be copied - Did we even run into a similar problem and had a similar solution (i.e. introduce a merge increment that "copies down" a class's internal structure)? Can we point to examples? Not many: but look at Classifier on the right hand side of figure 9.2 . it is an exact analogy. Also Classifier in 17.18 copies down the fact that it inherits from Namespace. - What is supposed to be copied exactly? are we proposing copying needed attributes, association, along with their operations, constraints..etc ? We only copy exactly what is needed (you.ve already done that bit). Anything else would get merged later - This means the metamodel and the spec doc will have exact copies of considerable subclauses, dose that include their related text..etc? (I have not seen repeated description in the spec, aside from the known redundancy between infrastructyre/superstructre, but I might have overlooked things I don.t think related text is necessary, by analogy with figures 9.2 and 17.18, where there is none. Solution 2 We need to refactor Connector::kind to put it into an appropriate level where it has access to needed features, avoiding the "copy down". - Is there a logical place to put in Connector::kind? I explicitly decided not to do this in the original resolution, so this could not be an editorial change, and would conflict with the fact that we already voted on the resolution. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook wrote on 07/21/2009 05:09:43 AM: > I am very happy to leave this to as an editorial change if nobody > objects. It doesn.t affect the semantics, and I don.t really know > how to submit a new issue for it . .resolution for 7364 doesn.t > include copying down necessary bits. doesn.t seem a sensible issue > that folks are likely to vote against. > > -- Steve > > From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: 20 July 2009 22:08 > To: Ed Seidewitz; Steve Cook > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > I consider copying classes/features an editorial change because the > resulting package will have the copied classes/features anyway. > It is however unfortunate that we didn.t catch this in the ballot review. > > - Nicolas. > > On 7/20/09 1:50 PM, "Ed Seidewitz" wrote: > Steve . > > Would it be better to submit a new issue and make the resolution for > that, since, technically, we have already resolved 7364? > > -- Ed > > > From: Steve Cook [mailto:Steve.Cook@microsoft.com] > Sent: Monday, July 20, 2009 4:20 PM > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > I suggest that tomorrow I formulate a revised resolution for 7364 > and put it into ballot 9 for a vote. > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com] > Sent: 20 July 2009 19:40 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is the only one I am hesistant to introduce editorial > changes for, just because of the amount of "copying down" I have to > do in both the metamodel and the spec doc. > > Also, I am not aware of any other situation where we had to "copy > down" featurs, constrants..with their details, , other than > introducing similary named Types as merge increments (can someone > point me to examples?) > > The other alternative is to > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 11:19 AM > [image removed] To [image removed] > Maged Elaasar/Ottawa/IBM@IBMCA > [image removed] cc [image removed] > "uml2-rtf@omg.org" > [image removed] Subject [image removed] > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > My own views on this inline. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com] > Sent: 20 July 2009 16:08 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is what I had to copy into BasicComponents to make the > OCL derivation of Connector::kind parse: > > result = > if end->exists( > role.oclIsKindOf(Port) > and partWithPort->isEmpty() > and not role.oclAsType(Port).isBehavior) > then ConnectorKind::delegation > else ConnectorKind::assembly > endif > > [image removed] > > My questions: > > 1) I know we introduced merge increments before by introducing > similarly named Classes, but did we "copy down" attributes, > associations...etc from the original Class? > > I don.t see any alternative, given the merge conventions we > are using. > > 2) If we copied down stuff, did we copy all their constraints, > subsetting...etc? In the set I copied here, there are a bunch of > subsetting, constraints...etc like derivation for > ConnectableElement::end and constraints on ConnectorEnd::partWithPort > > Since there is no way not to have that stuff in the end > result because of the merge rules, I don.t see why we would need to > include it. > > 3) If we copied down stuff, don't we also have to copy down their > subclauses, i.e. in this case introduce 4 new subclauses under 8.3 > with copy down of various sections > > That.s a matter of spec convention about which I am no > expert. I just think in general that redundancy is bad, so why > introduce it? > > 4) If we copied down stuff, doesn't this introduce a maintainnce problem? > > Yes: but the problem would not exist if we implemented the > package merges properly! The original point of package merge was to > remove redundancy, not to add it. > > 5) Is this an editorial change? > > I don.t know. > > > > Thanks, > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 10:17 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > The reason I didn.t suggest moving stuff to chapter 9 in the > original resolution is because (1) it involves significant re- > organization, and (2) a Connector has a .contract. in Components > that it doesn.t have in InternalStructures, and there is text in > chapter 8 that talks about this. I definitely don.t think we could > do all this as an editorial change. > > I think that the copying solution just needs ConnectorEnd and > Property with the partWithPort and ends associations added to figure > 8.3 (assuming the OCL can refer to the type Port without having to > copy that as well). > > -- Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 20 July 2009 15:00 > To: Maged Elaasar > Cc: Steve Cook; uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Actually this might not work as the derivation of 'kind' also refers > to Ports::ConnectorEnd.partwithPort, which would not be avaiable in > InternalStructures. > > My only concern about the copying solution is how much I have to > copy to bring all what is needed for the derivation, and whether > this can pass as editorial change since it could mean introducing > whole new subclases. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM > To > Steve Cook > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Steve, > > Given that Connector::kind's derivation dependency on internal > structures, doesn't it make more sense to move/merge Connector and > ConnectorEnd from BasicComponents to InternalStructures? > > Another reason is that Connector is not referenced by any other > Class in BasicComponents. Look at figures 8.2 and 8.3 > > Opinions? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 12:41 PM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Ok. Given this and Jim.s email it seems that we have a convention > about merges which is different from what I understood. > > With regard to Connector::end, I guess the solution is to copy > ConnectorEnd down into BasicComponents, as well as the containment > relationship. Given the merge semantics, that is a completely neutral change. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 17 July 2009 16:36 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, > > This is not what I understand about the package merge relationships. > > My understanding is that if we have two packages P1 and P2, where P1 > has a package merge to P2, then class P1::C1 does not have direct > access to properties in P2::C1, but it needs to "copy" them in order > to be able to access them. > > This is similar I think to a Class having an InterfaceRealization to > an Interface. The class does not have access to the interface's > properties unless it "copies" them down, i.e. have ones with similarsignature. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 10:38 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I disagree. > > You say (in your other email): .Since the spec sections are > documenting things "before" the merge .... > > Here.s figure 8.1 from the spec (hopefully the email system will > transfer this): > > [image removed] > > This states clearly that PackagingComponents merges BasicComponents, > and so on. This has nothing to do with L1, L2, L3 etc: it is the > normative specification of PackagingComponents. Similarly, > BasicComponents merges StructuredClasses. According to the extensive > explanation in chapter 7, this definitely does mean that the merge > happens here. So it is not true that .The spec suggests that there > is BasicComponents::Connector merges with InternalStructures:: > Connector in some merge level.. These merges are not suggestions > about some merge level, they are definitive (normative) statements > about the definition of these actual packages, and are also > represented in the XMI for UML http://www.omg. > org/spec/UML/20080501/Superstructure.xmi org/spec/UML/20080501/Superstructure.xmi> . > > - -Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 17 July 2009 15:23 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Componnts) > > Steve, The spec suggests that there is BasicComponents::Connector > merges with InternalStructures::Connector in some merge level. It > does not mean that the BasicComponents::Connector class is the > result of this merge, and hence it cannot assume access to features > of that Class. Imagine the case when this class merges with > something else, then the assumption of haing access to the features > of a particular merged_with Class is not valid. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 05:30 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I must be misunderstanding something. > > You say .The property is available in InternalStructures::Connector > but BasicComponents::Connector merges with that class.. > > Section 7.3.40 says .a package merge can be viewed as an operation > that takes the contents of two packages and produces a new package > that combines the contents of the packages involved in the merge. > > How can this not mean that Connector::end is available in > BasicComponents::Connector? > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > ] > Sent: 17 July 2009 03:38 > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > Another problem with this resolution. The OCL for derivation of > "kind" refers to the "Connector::end" property and gives parse error > as this property is not available in BasicComponents::Connector. > > The property is available in InternalStructures::Connector but > BasicComponents::Connector merges with that class and does not have > a generalization to it (it actually does not have any generalization) > > How do I address this? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM > To > uml2-rtf@omg.org > cc [image removed] > Subject > resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > The resolution is making Connector::kind a derived property. > Currently the metamodel has the multiplicity of this property as > [0..1]. Is this the desired multiplicity after making this property > derived? Wouldn't it be [1]? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 [image removed] From: "Rouquette, Nicolas F (316A)" To: Maged Elaasar , Steve Cook CC: Ed Seidewitz , "uml2-rtf@omg.org" Date: Tue, 21 Jul 2009 10:16:49 -0700 Subject: Re: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoKJVnmgtDRby+cRN+YENDxmZK6LAAAa48V Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Maged, In the metamodel, look at InternalStructures::Classifier. It is there because of the fact that InternalStructures::Property adds specific content . i.e., a generalization to ConnectableElement. So, when StructuredClassifier::ownedAttribute subsets Classifier::attribute, the intent of this particular merge increment was that the relevant parts of Classifier and Classifier::property would be copied down from Kernel in InternalStructures. Notice that in the spec document, InternalStructures is covered in clause 9 (Components) where it is explicitly merged there (Fig. 9.1). The key point here is that Classifier (9.3.2) says *nothing* about InternalStructures::Classifier because there is *nothing* to be said about this at all. InternalStructures::Classifier is only a pure copy of the relevant parts of Kernel::Classifier to make it clear that StructuredClassifier::ownedAttribute should be subsetting InternalStructures::attribute and *not* Kernel::Classifier::atttribute. Furthermore, InternalStructures::StructuredClassifier should specialize InternalStructures::Classifier and not Kernel::Classifier. In the resulting package, this doens.t make a difference but from a package merge purist perspective, it is yucky. So, besides the copy-down you described in the figure a few days ago (red things), please make editorial changes in InternalStructures: InternalStructures::StructuredClassifier should specialize InternalStructures::Classifier instead of Kernel::Classifier InternalStructures::StructuredClassifier::ownedAttribute should subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. If now, there is really no point in having InternalStructures::Classifier at all. Since it is there, I believe it is more consistent with the idea of copying the relevant parts of merged package contents in the receiving package context to make OCL, subsets and redefinitions well-formed. - Nicolas. On 7/21/09 10:04 AM, "Maged Elaasar" wrote: Steve, so you are suggesting I do the copying in the metamodel what is enough to make the constraint parse and update Figure 8.3, without copying the corresponding spec text? Wouldn't this leave the metamodel and spec not in sync? I mean it would make the maintaince of this part harder since in the future we have to remember to updat the metamodel part in components based on changes to composite structure. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/21/2009 12:44 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged My answers inline. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 17:13 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, I just want us to answer some questions first before we take action: The problem The issue we are talkig about proposes converting BasicComponents::Connector::kind from a non-derived to a derived attribute. The proposed derivation relies on features of Connector that are only available in CompositeStructure subclauses and not in Components, like connector ends, ports..etc. The current writeup about connector kind is in the components subclause. Solution 1 The voted on resolution suggests putting the derivation of "kind" in components, but since we do not have access to the appropriate features, the suggestion now is to "copy down" things from CompositeStructure to Componnets. Yes: because the semantics of package merge tell us that we really should have access to those things, but because of the way package merge is implemented in the UML spec, they have to be copied - Did we even run into a similar problem and had a similar solution (i.e. introduce a merge increment that "copies down" a class's internal structure)? Can we point to examples? Not many: but look at Classifier on the right hand side of figure 9.2 . it is an exact analogy. Also Classifier in 17.18 copies down the fact that it inherits from Namespace. - What is supposed to be copied exactly? are we proposing copying needed attributes, association, along with their operations, constraints..etc ? We only copy exactly what is needed (you.ve already done that bit). Anything else would get merged later - This means the metamodel and the spec doc will have exact copies of considerable subclauses, dose that include their related text..etc? (I have not seen repeated description in the spec, aside from the known redundancy between infrastructyre/superstructre, but I might have overlooked things I don.t think related text is necessary, by analogy with figures 9.2 and 17.18, where there is none. Solution 2 We need to refactor Connector::kind to put it into an appropriate level where it has access to needed features, avoiding the "copy down". - Is there a logical place to put in Connector::kind? I explicitly decided not to do this in the original resolution, so this could not be an editorial change, and would conflict with the fact that we already voted on the resolution. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook wrote on 07/21/2009 05:09:43 AM: > I am very happy to leave this to as an editorial change if nobody > objects. It doesn.t affect the semantics, and I don.t really know > how to submit a new issue for it . .resolution for 7364 doesn.t > include copying down necessary bits. doesn.t seem a sensible issue > that folks are likely to vote against. > > -- Steve > > From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov ] > Sent: 20 July 2009 22:08 > To: Ed Seidewitz; Steve Cook > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > I consider copying classes/features an editorial change because the > resulting package will have the copied classes/features anyway. > It is however unfortunate that we didn.t catch this in the ballot review. > > - Nicolas. > > On 7/20/09 1:50 PM, "Ed Seidewitz" wrote: > Steve . > > Would it be better to submit a new issue and make the resolution for > that, since, technically, we have already resolved 7364? > > -- Ed > > > From: Steve Cook [mailto:Steve.Cook@microsoft.com ] > Sent: Monday, July 20, 2009 4:20 PM > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > I suggest that tomorrow I formulate a revised resolution for 7364 > and put it into ballot 9 for a vote. > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com ] > Sent: 20 July 2009 19:40 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is the only one I am hesistant to introduce editorial > changes for, just because of the amount of "copying down" I have to > do in both the metamodel and the spec doc. > > Also, I am not aware of any other situation where we had to "copy > down" featurs, constrants..with their details, , other than > introducing similary named Types as merge increments (can someone > point me to examples?) > > The other alternative is to > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 11:19 AM > [image removed] To [image removed] > Maged Elaasar/Ottawa/IBM@IBMCA > [image removed] cc [image removed] > "uml2-rtf@omg.org" > [image removed] Subject [image removed] > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > My own views on this inline. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com ] > Sent: 20 July 2009 16:08 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is what I had to copy into BasicComponents to make the > OCL derivation of Connector::kind parse: > > result = > if end->exists( > role.oclIsKindOf(Port) > and partWithPort->isEmpty() > and not role.oclAsType(Port).isBehavior) > then ConnectorKind::delegation > else ConnectorKind::assembly > endif > > [image removed] > > My questions: > > 1) I know we introduced merge increments before by introducing > similarly named Classes, but did we "copy down" attributes, > associations...etc from the original Class? > > I don.t see any alternative, given the merge conventions we > are using. > > 2) If we copied down stuff, did we copy all their constraints, > subsetting...etc? In the set I copied here, there are a bunch of > subsetting, constraints...etc like derivation for > ConnectableElement::end and constraints on ConnectorEnd::partWithPort > > Since there is no way not to have that stuff in the end > result because of the merge rules, I don.t see why we would need to > include it. > > 3) If we copied down stuff, don't we also have to copy down their > subclauses, i.e. in this case introduce 4 new subclauses under 8.3 > with copy down of various sections > > That.s a matter of spec convention about which I am no > expert. I just think in general that redundancy is bad, so why > introduce it? > > 4) If we copied down stuff, doesn't this introduce a maintainnce problem? > > Yes: but the problem would not exist if we implemented the > package merges properly! The original point of package merge was to > remove redundancy, not to add it. > > 5) Is this an editorial change? > > I don.t know. > > > > Thanks, > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 10:17 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > The reason I didn.t suggest moving stuff to chapter 9 in the > original resolution is because (1) it involves significant re- > organization, and (2) a Connector has a .contract. in Components > that it doesn.t have in InternalStructures, and there is text in > chapter 8 that talks about this. I definitely don.t think we could > do all this as an editorial change. > > I think that the copying solution just needs ConnectorEnd and > Property with the partWithPort and ends associations added to figure > 8.3 (assuming the OCL can refer to the type Port without having to > copy that as well). > > -- Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 20 July 2009 15:00 > To: Maged Elaasar > Cc: Steve Cook; uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Actually this might not work as the derivation of 'kind' also refers > to Ports::ConnectorEnd.partwithPort, which would not be avaiable in > InternalStructures. > > My only concern about the copying solution is how much I have to > copy to bring all what is needed for the derivation, and whether > this can pass as editorial change since it could mean introducing > whole new subclases. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM > To > Steve Cook > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Steve, > > Given that Connector::kind's derivation dependency on internal > structures, doesn't it make more sense to move/merge Connector and > ConnectorEnd from BasicComponents to InternalStructures? > > Another reason is that Connector is not referenced by any other > Class in BasicComponents. Look at figures 8.2 and 8.3 > > Opinions? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 12:41 PM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Ok. Given this and Jim.s email it seems that we have a convention > about merges which is different from what I understood. > > With regard to Connector::end, I guess the solution is to copy > ConnectorEnd down into BasicComponents, as well as the containment > relationship. Given the merge semantics, that is a completely neutral change. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 17 July 2009 16:36 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, > > This is not what I understand about the package merge relationships. > > My understanding is that if we have two packages P1 and P2, where P1 > has a package merge to P2, then class P1::C1 does not have direct > access to properties in P2::C1, but it needs to "copy" them in order > to be able to access them. > > This is similar I think to a Class having an InterfaceRealization to > an Interface. The class does not have access to the interface's > properties unless it "copies" them down, i.e. have ones with similarsignature. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 10:38 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I disagree. > > You say (in your other email): .Since the spec sections are > documenting things "before" the merge .... > > Here.s figure 8.1 from the spec (hopefully the email system will > transfer this): > > [image removed] > > This states clearly that PackagingComponents merges BasicComponents, > and so on. This has nothing to do with L1, L2, L3 etc: it is the > normative specification of PackagingComponents. Similarly, > BasicComponents merges StructuredClasses. According to the extensive > explanation in chapter 7, this definitely does mean that the merge > happens here. So it is not true that .The spec suggests that there > is BasicComponents::Connector merges with InternalStructures:: > Connector in some merge level.. These merges are not suggestions > about some merge level, they are definitive (normative) statements > about the definition of these actual packages, and are also > represented in the XMI for UML http://www.omg . > org/spec/UML/20080501/Superstructure.xmi . > org/spec/UML/20080501/Superstructure.xmi> . > > - -Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 17 July 2009 15:23 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Componnts) > > Steve, The spec suggests that there is BasicComponents::Connector > merges with InternalStructures::Connector in some merge level. It > does not mean that the BasicComponents::Connector class is the > result of this merge, and hence it cannot assume access to features > of that Class. Imagine the case when this class merges with > something else, then the assumption of haing access to the features > of a particular merged_with Class is not valid. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 05:30 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I must be misunderstanding something. > > You say .The property is available in InternalStructures::Connector > but BasicComponents::Connector merges with that class.. > > Section 7.3.40 says .a package merge can be viewed as an operation > that takes the contents of two packages and produces a new package > that combines the contents of the packages involved in the merge. > > How can this not mean that Connector::end is available in > BasicComponents::Connector? > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 17 July 2009 03:38 > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > Another problem with this resolution. The OCL for derivation of > "kind" refers to the "Connector::end" property and gives parse error > as this property is not available in BasicComponents::Connector. > > The property is available in InternalStructures::Connector but > BasicComponents::Connector merges with that class and does not have > a generalization to it (it actually does not have any generalization) > > How do I address this? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM > To > uml2-rtf@omg.org > cc [image removed] > Subject > resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > The resolution is making Connector::kind a derived property. > Currently the metamodel has the multiplicity of this property as > [0..1]. Is this the desired multiplicity after making this property > derived? Wouldn't it be [1]? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 [image removed] From: "Rouquette, Nicolas F (316A)" To: Ed Seidewitz , Maged Elaasar , Steve Cook CC: "uml2-rtf@omg.org" Date: Tue, 21 Jul 2009 10:18:06 -0700 Subject: Re: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoKJWCMgv1uYN8ZS7yN1tuGROQTggAAHhIwAABXTQw= Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized No! The only time you need to explicitly acknowledge the classifiers/features copied down from a merged package increment is if something is changed or added in the context of the receiving package. Case in point: InternalStructures::Classifier and InternalStructures::Classifier::attribute. - Nicolas. On 7/21/09 10:14 AM, "Ed Seidewitz" wrote: Maged . If you .copy down. a class in the metamodel, then you do need to introduce a corresponding class description for the copied class in whatever subclause it was copied into. This class description should list all the copied attributes and associations. However, it is not necessary to repeat any descriptive text, other than perhaps an introductory sentence. Typically, this is where it is really useful to note in the Generalizations section that this is a merge increment of some other .base. version of the class, and then you can just refer to the subclause of this .base. version in the Semantics section of the copied down class description. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, July 21, 2009 1:04 PM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, so you are suggesting I do the copying in the metamodel what is enough to make the constraint parse and update Figure 8.3, without copying the corresponding spec text? Wouldn't this leave the metamodel and spec not in sync? I mean it would make the maintaince of this part harder since in the future we have to remember to updat the metamodel part in components based on changes to composite structure. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/21/2009 12:44 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged My answers inline. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 17:13 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, I just want us to answer some questions first before we take action: The problem The issue we are talkig about proposes converting BasicComponents::Connector::kind from a non-derived to a derived attribute. The proposed derivation relies on features of Connector that are only available in CompositeStructure subclauses and not in Components, like connector ends, ports..etc. The current writeup about connector kind is in the components subclause. Solution 1 The voted on resolution suggests putting the derivation of "kind" in components, but since we do not have access to the appropriate features, the suggestion now is to "copy down" things from CompositeStructure to Componnets. Yes: because the semantics of package merge tell us that we really should have access to those things, but because of the way package merge is implemented in the UML spec, they have to be copied - Did we even run into a similar problem and had a similar solution (i.e. introduce a merge increment that "copies down" a class's internal structure)? Can we point to examples? Not many: but look at Classifier on the right hand side of figure 9.2 . it is an exact analogy. Also Classifier in 17.18 copies down the fact that it inherits from Namespace. - What is supposed to be copied exactly? are we proposing copying needed attributes, association, along with their operations, constraints..etc ? We only copy exactly what is needed (you.ve already done that bit). Anything else would get merged later - This means the metamodel and the spec doc will have exact copies of considerable subclauses, dose that include their related text..etc? (I have not seen repeated description in the spec, aside from the known redundancy between infrastructyre/superstructre, but I might have overlooked things I don.t think related text is necessary, by analogy with figures 9.2 and 17.18, where there is none. Solution 2 We need to refactor Connector::kind to put it into an appropriate level where it has access to needed features, avoiding the "copy down". - Is there a logical place to put in Connector::kind? I explicitly decided not to do this in the original resolution, so this could not be an editorial change, and would conflict with the fact that we already voted on the resolution. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook wrote on 07/21/2009 05:09:43 AM: > I am very happy to leave this to as an editorial change if nobody > objects. It doesn.t affect the semantics, and I don.t really know > how to submit a new issue for it . .resolution for 7364 doesn.t > include copying down necessary bits. doesn.t seem a sensible issue > that folks are likely to vote against. > > -- Steve > > From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov ] > Sent: 20 July 2009 22:08 > To: Ed Seidewitz; Steve Cook > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > I consider copying classes/features an editorial change because the > resulting package will have the copied classes/features anyway. > It is however unfortunate that we didn.t catch this in the ballot review. > > - Nicolas. > > On 7/20/09 1:50 PM, "Ed Seidewitz" wrote: > Steve . > > Would it be better to submit a new issue and make the resolution for > that, since, technically, we have already resolved 7364? > > -- Ed > > > From: Steve Cook [mailto:Steve.Cook@microsoft.com ] > Sent: Monday, July 20, 2009 4:20 PM > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > I suggest that tomorrow I formulate a revised resolution for 7364 > and put it into ballot 9 for a vote. > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com ] > Sent: 20 July 2009 19:40 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is the only one I am hesistant to introduce editorial > changes for, just because of the amount of "copying down" I have to > do in both the metamodel and the spec doc. > > Also, I am not aware of any other situation where we had to "copy > down" featurs, constrants..with their details, , other than > introducing similary named Types as merge increments (can someone > point me to examples?) > > The other alternative is to > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 11:19 AM > [image removed] To [image removed] > Maged Elaasar/Ottawa/IBM@IBMCA > [image removed] cc [image removed] > "uml2-rtf@omg.org" > [image removed] Subject [image removed] > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > My own views on this inline. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com ] > Sent: 20 July 2009 16:08 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is what I had to copy into BasicComponents to make the > OCL derivation of Connector::kind parse: > > result = > if end->exists( > role.oclIsKindOf(Port) > and partWithPort->isEmpty() > and not role.oclAsType(Port).isBehavior) > then ConnectorKind::delegation > else ConnectorKind::assembly > endif > > [image removed] > > My questions: > > 1) I know we introduced merge increments before by introducing > similarly named Classes, but did we "copy down" attributes, > associations...etc from the original Class? > > I don.t see any alternative, given the merge conventions we > are using. > > 2) If we copied down stuff, did we copy all their constraints, > subsetting...etc? In the set I copied here, there are a bunch of > subsetting, constraints...etc like derivation for > ConnectableElement::end and constraints on ConnectorEnd::partWithPort > > Since there is no way not to have that stuff in the end > result because of the merge rules, I don.t see why we would need to > include it. > > 3) If we copied down stuff, don't we also have to copy down their > subclauses, i.e. in this case introduce 4 new subclauses under 8.3 > with copy down of various sections > > That.s a matter of spec convention about which I am no > expert. I just think in general that redundancy is bad, so why > introduce it? > > 4) If we copied down stuff, doesn't this introduce a maintainnce problem? > > Yes: but the problem would not exist if we implemented the > package merges properly! The original point of package merge was to > remove redundancy, not to add it. > > 5) Is this an editorial change? > > I don.t know. > > > > Thanks, > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 10:17 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > The reason I didn.t suggest moving stuff to chapter 9 in the > original resolution is because (1) it involves significant re- > organization, and (2) a Connector has a .contract. in Components > that it doesn.t have in InternalStructures, and there is text in > chapter 8 that talks about this. I definitely don.t think we could > do all this as an editorial change. > > I think that the copying solution just needs ConnectorEnd and > Property with the partWithPort and ends associations added to figure > 8.3 (assuming the OCL can refer to the type Port without having to > copy that as well). > > -- Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 20 July 2009 15:00 > To: Maged Elaasar > Cc: Steve Cook; uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Actually this might not work as the derivation of 'kind' also refers > to Ports::ConnectorEnd.partwithPort, which would not be avaiable in > InternalStructures. > > My only concern about the copying solution is how much I have to > copy to bring all what is needed for the derivation, and whether > this can pass as editorial change since it could mean introducing > whole new subclases. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM > To > Steve Cook > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Steve, > > Given that Connector::kind's derivation dependency on internal > structures, doesn't it make more sense to move/merge Connector and > ConnectorEnd from BasicComponents to InternalStructures? > > Another reason is that Connector is not referenced by any other > Class in BasicComponents. Look at figures 8.2 and 8.3 > > Opinions? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 12:41 PM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Ok. Given this and Jim.s email it seems that we have a convention > about merges which is different from what I understood. > > With regard to Connector::end, I guess the solution is to copy > ConnectorEnd down into BasicComponents, as well as the containment > relationship. Given the merge semantics, that is a completely neutral change. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 17 July 2009 16:36 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, > > This is not what I understand about the package merge relationships. > > My understanding is that if we have two packages P1 and P2, where P1 > has a package merge to P2, then class P1::C1 does not have direct > access to properties in P2::C1, but it needs to "copy" them in order > to be able to access them. > > This is similar I think to a Class having an InterfaceRealization to > an Interface. The class does not have access to the interface's > properties unless it "copies" them down, i.e. have ones with similarsignature. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 10:38 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I disagree. > > You say (in your other email): .Since the spec sections are > documenting things "before" the merge .... > > Here.s figure 8.1 from the spec (hopefully the email system will > transfer this): > > [image removed] > > This states clearly that PackagingComponents merges BasicComponents, > and so on. This has nothing to do with L1, L2, L3 etc: it is the > normative specification of PackagingComponents. Similarly, > BasicComponents merges StructuredClasses. According to the extensive > explanation in chapter 7, this definitely does mean that the merge > happens here. So it is not true that .The spec suggests that there > is BasicComponents::Connector merges with InternalStructures:: > Connector in some merge level.. These merges are not suggestions > about some merge level, they are definitive (normative) statements > about the definition of these actual packages, and are also > represented in the XMI for UML http://www.omg . > org/spec/UML/20080501/Superstructure.xmi . > org/spec/UML/20080501/Superstructure.xmi> . > > - -Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 17 July 2009 15:23 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Componnts) > > Steve, The spec suggests that there is BasicComponents::Connector > merges with InternalStructures::Connector in some merge level. It > does not mean that the BasicComponents::Connector class is the > result of this merge, and hence it cannot assume access to features > of that Class. Imagine the case when this class merges with > something else, then the assumption of haing access to the features > of a particular merged_with Class is not valid. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 05:30 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I must be misunderstanding something. > > You say .The property is available in InternalStructures::Connector > but BasicComponents::Connector merges with that class.. > > Section 7.3.40 says .a package merge can be viewed as an operation > that takes the contents of two packages and produces a new package > that combines the contents of the packages involved in the merge. > > How can this not mean that Connector::end is available in > BasicComponents::Connector? > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 17 July 2009 03:38 > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > Another problem with this resolution. The OCL for derivation of > "kind" refers to the "Connector::end" property and gives parse error > as this property is not available in BasicComponents::Connector. > > The property is available in InternalStructures::Connector but > BasicComponents::Connector merges with that class and does not have > a generalization to it (it actually does not have any generalization) > > How do I address this? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM > To > uml2-rtf@omg.org > cc [image removed] > Subject > resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > The resolution is making Connector::kind a derived property. > Currently the metamodel has the multiplicity of this property as > [0..1]. Is this the desired multiplicity after making this property > derived? Wouldn't it be [1]? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 [image removed] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jB8WMPZW+B8ZMGuWLsLsy2WNXY0mizLPmXodfXkqLI8=; b=XUyjZ/Cruhjb6mzzVl27VYckHgjSZqswKO116JUGDrcDHX3tLKYJgAAyI0OUa7KOIO NFyOm5c/kJDN5kLoNl9ZrU3dGhp/n5GR18Z6bfRfTfPu1Wv68AFjFZqfVb23DZ7vnwbX Ntqx3Zq3BxDUDdtc9h5Pl/56EzfpaTIMJoFSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UeHkfquhkKu3p/LAZmFgkyNARssOlayMIB8rUXaH9/73MEd2EKItyOrNSZ5OUg2I2D 248mHyuf2t4YqVMmZfhkRyJ8JS+DcTcopquK2nLBWG6CFDPcCFHy9RdpSQvOihmzE4RW huR6h2fm1wUnOhrnhwAg8pMjhN9hy4/I8WWCo= Date: Tue, 21 Jul 2009 13:40:23 -0400 Subject: Re: resolution 7364 from ballot 8 (Components) From: Bran Selic To: Steve Cook Cc: Maged Elaasar , Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Although I am no longer officially involved, I would strongly advise against such major "editorial" changes. My objection is purely from a procedural pint of view (the technical issue is separate) -- it sets a bad precedent and gives too much power to the document editor. (Note that Steve's response invokes precedence, which means that precedence matters and, therefore, we should avoid setting bad ones.) I really think you should solve this with another issue -- these things are cheap and easy to obtain. And, in this case, you have an outstanding ballot in which to squeeze it. Cheers...Bran DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nOaIdyFqKjlQjxovIPdcfR+4vdRmwWrjwz9VcRKfzTA=; b=U69nionoSXXKnFGPf5qclnc7groOS93nhZc+ffjn3iLRCGiyTqXZsaFMAUE6xP1fIi Sh3RZiQNzVlprgGzOrhsJo860ip2R07jlulC9ZrxYeSrVXs3irEXZ0V3wfgMViqrFctl ZAVuRNthJ4OnIibCgaCG628Sk4TmGoWXvGwB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OdRx5Np80AzvlT8kUVMV7aSbDcdLmM62HEjsHOJYdvWx+2PDNfQh+6BwwtOJohY16p pdpaknVOFi6+BtnGsz/Exg6g3dCcxjaAfs/6xjVmG9MZYRGDEs63+pkAow2O3myb3UtL ZgAiA8CtnQQwxn2s5lmlYoRHgXgmltm7cc3/k= Date: Tue, 21 Jul 2009 13:57:33 -0400 Subject: Re: resolution 7364 from ballot 8 (Components) From: Bran Selic To: Steve Cook Cc: Maged Elaasar , Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" - Did we even run into a similar problem and had a similar solution (i.e. introduce a merge increment that "copies down" a class's internal structure)? Can we point to examples? Not many: but look at Classifier on the right hand side of figure 9.2 . it is an exact analogy. Also Classifier in 17.18 copies down the fact that it inherits from Namespace. The inclusion of Classifier in figure 9.2 is a bug (my fault probably). Based on the conventions used for the diagrams, it should not have been there since there is no local increment in Classifier in the InternalStructures package. The convention used in the diagrams was that locally defined elements representing either new metaclasses or metaclass increments, do not have a fully-qualified name -- this is how you can spot that they are new or increments. Anything from an external package should have a fully qualified name. The case of 17.18 is different, since there is a local increment of Classifier in the package. Cheers...bran Subject: RE: resolution 7364 from ballot 8 (Components) Date: Tue, 21 Jul 2009 14:19:02 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: resolution 7364 from ballot 8 (Components) thread-index: AcoKJWCMgv1uYN8ZS7yN1tuGROQTggAAHhIwAABXTQwAAeB84A== From: "Ed Seidewitz" To: "Rouquette, Nicolas F (316A)" Cc: Nicolas . Hmmm.perhaps you are right. The examples I was looking at do all seem to add something specific to the containing package, not just attributes and associations .copied down.. However, as Bran pointed out, there is no InternalStructures::Classifier . the diagram in Figure 9.2 is in error by not showing the full qualification for Classes::Kernel::Classifier on the far right of the diagram. As far as I can see, there is no need to copy down Classifier::attribute, since I can.t find that it is referenced anywhere in the clause.other than in its subsetting by StructuredClassifier::ownedAttribute, which doesn.t require it to be copied down. So, do we really have any previous precedent at all for .copying down. a class as is now being proposed?? -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, July 21, 2009 1:18 PM To: Ed Seidewitz; Maged Elaasar; Steve Cook Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) No! The only time you need to explicitly acknowledge the classifiers/features copied down from a merged package increment is if something is changed or added in the context of the receiving package. Case in point: InternalStructures::Classifier and InternalStructures::Classifier::attribute. - Nicolas. On 7/21/09 10:14 AM, "Ed Seidewitz" wrote: Maged . If you .copy down. a class in the metamodel, then you do need to introduce a corresponding class description for the copied class in whatever subclause it was copied into. This class description should list all the copied attributes and associations. However, it is not necessary to repeat any descriptive text, other than perhaps an introductory sentence. Typically, this is where it is really useful to note in the Generalizations section that this is a merge increment of some other .base. version of the class, and then you can just refer to the subclause of this .base. version in the Semantics section of the copied down class description. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, July 21, 2009 1:04 PM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, so you are suggesting I do the copying in the metamodel what is enough to make the constraint parse and update Figure 8.3, without copying the corresponding spec text? Wouldn't this leave the metamodel and spec not in sync? I mean it would make the maintaince of this part harder since in the future we have to remember to updat the metamodel part in components based on changes to composite structure. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/21/2009 12:44 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged My answers inline. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 17:13 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, I just want us to answer some questions first before we take action: The problem The issue we are talkig about proposes converting BasicComponents::Connector::kind from a non-derived to a derived attribute. The proposed derivation relies on features of Connector that are only available in CompositeStructure subclauses and not in Components, like connector ends, ports..etc. The current writeup about connector kind is in the components subclause. Solution 1 The voted on resolution suggests putting the derivation of "kind" in components, but since we do not have access to the appropriate features, the suggestion now is to "copy down" things from CompositeStructure to Componnets. Yes: because the semantics of package merge tell us that we really should have access to those things, but because of the way package merge is implemented in the UML spec, they have to be copied - Did we even run into a similar problem and had a similar solution (i.e. introduce a merge increment that "copies down" a class's internal structure)? Can we point to examples? Not many: but look at Classifier on the right hand side of figure 9.2 . it is an exact analogy. Also Classifier in 17.18 copies down the fact that it inherits from Namespace. - What is supposed to be copied exactly? are we proposing copying needed attributes, association, along with their operations, constraints..etc ? We only copy exactly what is needed (you.ve already done that bit). Anything else would get merged later - This means the metamodel and the spec doc will have exact copies of considerable subclauses, dose that include their related text..etc? (I have not seen repeated description in the spec, aside from the known redundancy between infrastructyre/superstructre, but I might have overlooked things I don.t think related text is necessary, by analogy with figures 9.2 and 17.18, where there is none. Solution 2 We need to refactor Connector::kind to put it into an appropriate level where it has access to needed features, avoiding the "copy down". - Is there a logical place to put in Connector::kind? I explicitly decided not to do this in the original resolution, so this could not be an editorial change, and would conflict with the fact that we already voted on the resolution. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook wrote on 07/21/2009 05:09:43 AM: > I am very happy to leave this to as an editorial change if nobody > objects. It doesn.t affect the semantics, and I don.t really know > how to submit a new issue for it . .resolution for 7364 doesn.t > include copying down necessary bits. doesn.t seem a sensible issue > that folks are likely to vote against. > > -- Steve > > From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov ] > Sent: 20 July 2009 22:08 > To: Ed Seidewitz; Steve Cook > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > I consider copying classes/features an editorial change because the > resulting package will have the copied classes/features anyway. > It is however unfortunate that we didn.t catch this in the ballot review. > > - Nicolas. > > On 7/20/09 1:50 PM, "Ed Seidewitz" wrote: > Steve . > > Would it be better to submit a new issue and make the resolution for > that, since, technically, we have already resolved 7364? > > -- Ed > > > From: Steve Cook [mailto:Steve.Cook@microsoft.com ] > Sent: Monday, July 20, 2009 4:20 PM > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > I suggest that tomorrow I formulate a revised resolution for 7364 > and put it into ballot 9 for a vote. > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com ] > Sent: 20 July 2009 19:40 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is the only one I am hesistant to introduce editorial > changes for, just because of the amount of "copying down" I have to > do in both the metamodel and the spec doc. > > Also, I am not aware of any other situation where we had to "copy > down" featurs, constrants..with their details, , other than > introducing similary named Types as merge increments (can someone > point me to examples?) > > The other alternative is to > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 11:19 AM > [image removed] To [image removed] > Maged Elaasar/Ottawa/IBM@IBMCA > [image removed] cc [image removed] > "uml2-rtf@omg.org" > [image removed] Subject [image removed] > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > My own views on this inline. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com ] > Sent: 20 July 2009 16:08 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is what I had to copy into BasicComponents to make the > OCL derivation of Connector::kind parse: > > result = > if end->exists( > role.oclIsKindOf(Port) > and partWithPort->isEmpty() > and not role.oclAsType(Port).isBehavior) > then ConnectorKind::delegation > else ConnectorKind::assembly > endif > > [image removed] > > My questions: > > 1) I know we introduced merge increments before by introducing > similarly named Classes, but did we "copy down" attributes, > associations...etc from the original Class? > > I don.t see any alternative, given the merge conventions we > are using. > > 2) If we copied down stuff, did we copy all their constraints, > subsetting...etc? In the set I copied here, there are a bunch of > subsetting, constraints...etc like derivation for > ConnectableElement::end and constraints on ConnectorEnd::partWithPort > > Since there is no way not to have that stuff in the end > result because of the merge rules, I don.t see why we would need to > include it. > > 3) If we copied down stuff, don't we also have to copy down their > subclauses, i.e. in this case introduce 4 new subclauses under 8.3 > with copy down of various sections > > That.s a matter of spec convention about which I am no > expert. I just think in general that redundancy is bad, so why > introduce it? > > 4) If we copied down stuff, doesn't this introduce a maintainnce problem? > > Yes: but the problem would not exist if we implemented the > package merges properly! The original point of package merge was to > remove redundancy, not to add it. > > 5) Is this an editorial change? > > I don.t know. > > > > Thanks, > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 10:17 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > The reason I didn.t suggest moving stuff to chapter 9 in the > original resolution is because (1) it involves significant re- > organization, and (2) a Connector has a .contract. in Components > that it doesn.t have in InternalStructures, and there is text in > chapter 8 that talks about this. I definitely don.t think we could > do all this as an editorial change. > > I think that the copying solution just needs ConnectorEnd and > Property with the partWithPort and ends associations added to figure > 8.3 (assuming the OCL can refer to the type Port without having to > copy that as well). > > -- Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 20 July 2009 15:00 > To: Maged Elaasar > Cc: Steve Cook; uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Actually this might not work as the derivation of 'kind' also refers > to Ports::ConnectorEnd.partwithPort, which would not be avaiable in > InternalStructures. > > My only concern about the copying solution is how much I have to > copy to bring all what is needed for the derivation, and whether > this can pass as editorial change since it could mean introducing > whole new subclases. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM > To > Steve Cook > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Steve, > > Given that Connector::kind's derivation dependency on internal > structures, doesn't it make more sense to move/merge Connector and > ConnectorEnd from BasicComponents to InternalStructures? > > Another reason is that Connector is not referenced by any other > Class in BasicComponents. Look at figures 8.2 and 8.3 > > Opinions? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 12:41 PM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Ok. Given this and Jim.s email it seems that we have a convention > about merges which is different from what I understood. > > With regard to Connector::end, I guess the solution is to copy > ConnectorEnd down into BasicComponents, as well as the containment > relationship. Given the merge semantics, that is a completely neutral change. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 17 July 2009 16:36 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, > > This is not what I understand about the package merge relationships. > > My understanding is that if we have two packages P1 and P2, where P1 > has a package merge to P2, then class P1::C1 does not have direct > access to properties in P2::C1, but it needs to "copy" them in order > to be able to access them. > > This is similar I think to a Class having an InterfaceRealization to > an Interface. The class does not have access to the interface's > properties unless it "copies" them down, i.e. have ones with similarsignature. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 10:38 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I disagree. > > You say (in your other email): .Since the spec sections are > documenting things "before" the merge .... > > Here.s figure 8.1 from the spec (hopefully the email system will > transfer this): > > [image removed] > > This states clearly that PackagingComponents merges BasicComponents, > and so on. This has nothing to do with L1, L2, L3 etc: it is the > normative specification of PackagingComponents. Similarly, > BasicComponents merges StructuredClasses. According to the extensive > explanation in chapter 7, this definitely does mean that the merge > happens here. So it is not true that .The spec suggests that there > is BasicComponents::Connector merges with InternalStructures:: > Connector in some merge level.. These merges are not suggestions > about some merge level, they are definitive (normative) statements > about the definition of these actual packages, and are also > represented in the XMI for UML http://www.omg . > org/spec/UML/20080501/Superstructure.xmi . > org/spec/UML/20080501/Superstructure.xmi> . > > - -Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 17 July 2009 15:23 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Componnts) > > Steve, The spec suggests that there is BasicComponents::Connector > merges with InternalStructures::Connector in some merge level. It > does not mean that the BasicComponents::Connector class is the > result of this merge, and hence it cannot assume access to features > of that Class. Imagine the case when this class merges with > something else, then the assumption of haing access to the features > of a particular merged_with Class is not valid. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 05:30 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I must be misunderstanding something. > > You say .The property is available in InternalStructures::Connector > but BasicComponents::Connector merges with that class.. > > Section 7.3.40 says .a package merge can be viewed as an operation > that takes the contents of two packages and produces a new package > that combines the contents of the packages involved in the merge. > > How can this not mean that Connector::end is available in > BasicComponents::Connector? > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 17 July 2009 03:38 > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > Another problem with this resolution. The OCL for derivation of > "kind" refers to the "Connector::end" property and gives parse error > as this property is not available in BasicComponents::Connector. > > The property is available in InternalStructures::Connector but > BasicComponents::Connector merges with that class and does not have > a generalization to it (it actually does not have any generalization) > > How do I address this? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM > To > uml2-rtf@omg.org > cc [image removed] > Subject > resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > The resolution is making Connector::kind a derived property. > Currently the metamodel has the multiplicity of this property as > [0..1]. Is this the desired multiplicity after making this property > derived? Wouldn't it be [1]? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 [image removed] Subject: RE: resolution 7364 from ballot 8 (Components) To: "Ed Seidewitz" Cc: "Rouquette, Nicolas F (316A)" , uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Tue, 21 Jul 2009 14:23:45 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/21/2009 14:23:47 Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/21/2009 02:19 PM To "Rouquette, Nicolas F (316A)" cc Subject RE: resolution 7364 from ballot 8 (Components) Nicolas . Hmmm.perhaps you are right. The examples I was looking at do all seem to add something specific to the containing package, not just attributes and associations .copied down.. However, as Bran pointed out, there is no InternalStructures::Classifier . the diagram in Figure 9.2 is in error by not showing the full qualification for Classes::Kernel::Classifier on the far right of the diagram. As far as I can see, there is no need to copy down Classifier::attribute, since I can.t find that it is referenced anywhere in the clause.other than in its subsetting by StructuredClassifier::ownedAttribute, which doesn.t require it to be copied down. So, do we really have any previous precedent at all for .copying down. a class as is now being proposed?? -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, July 21, 2009 1:18 PM To: Ed Seidewitz; Maged Elaasar; Steve Cook Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) No! The only time you need to explicitly acknowledge the classifiers/features copied down from a merged package increment is if something is changed or added in the context of the receiving package. Case in point: InternalStructures::Classifier and InternalStructures::Classifier::attribute. - Nicolas. On 7/21/09 10:14 AM, "Ed Seidewitz" wrote: Maged . If you .copy down. a class in the metamodel, then you do need to introduce a corresponding class description for the copied class in whatever subclause it was copied into. This class description should list all the copied attributes and associations. However, it is not necessary to repeat any descriptive text, other than perhaps an introductory sentence. Typically, this is where it is really useful to note in the Generalizations section that this is a merge increment of some other .base. version of the class, and then you can just refer to the subclause of this .base. version in the Semantics section of the copied down class description. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, July 21, 2009 1:04 PM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, so you are suggesting I do the copying in the metamodel what is enough to make the constraint parse and update Figure 8.3, without copying the corresponding spec text? Wouldn't this leave the metamodel and spec not in sync? I mean it would make the maintaince of this part harder since in the future we have to remember to updat the metamodel part in components based on changes to composite structure. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/21/2009 12:44 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged My answers inline. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 17:13 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, I just want us to answer some questions first before we take action: The problem The issue we are talkig about proposes converting BasicComponents::Connector::kind from a non-derived to a derived attribute. The proposed derivation relies on features of Connector that are only available in CompositeStructure subclauses and not in Components, like connector ends, ports..etc. The current writeup about connector kind is in the components subclause. Solution 1 The voted on resolution suggests putting the derivation of "kind" in components, but since we do not have access to the appropriate features, the suggestion now is to "copy down" things from CompositeStructure to Componnets. Yes: because the semantics of package merge tell us that we really should have access to those things, but because of the way package merge is implemented in the UML spec, they have to be copied - Did we even run into a similar problem and had a similar solution (i.e. introduce a merge increment that "copies down" a class's internal structure)? Can we point to examples? Not many: but look at Classifier on the right hand side of figure 9.2 . it is an exact analogy. Also Classifier in 17.18 copies down the fact that it inherits from Namespace. - What is supposed to be copied exactly? are we proposing copying needed attributes, association, along with their operations, constraints..etc ? We only copy exactly what is needed (you.ve already done that bit). Anything else would get merged later - This means the metamodel and the spec doc will have exact copies of considerable subclauses, dose that include their related text..etc? (I have not seen repeated description in the spec, aside from the known redundancy between infrastructyre/superstructre, but I might have overlooked things I don.t think related text is necessary, by analogy with figures 9.2 and 17.18, where there is none. Solution 2 We need to refactor Connector::kind to put it into an appropriate level where it has access to needed features, avoiding the "copy down". - Is there a logical place to put in Connector::kind? I explicitly decided not to do this in the original resolution, so this could not be an editorial change, and would conflict with the fact that we already voted on the resolution. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook wrote on 07/21/2009 05:09:43 AM: > I am very happy to leave this to as an editorial change if nobody > objects. It doesn.t affect the semantics, and I don.t really know > how to submit a new issue for it . .resolution for 7364 doesn.t > include copying down necessary bits. doesn.t seem a sensible issue > that folks are likely to vote against. > > -- Steve > > From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov ] > Sent: 20 July 2009 22:08 > To: Ed Seidewitz; Steve Cook > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > I consider copying classes/features an editorial change because the > resulting package will have the copied classes/features anyway. > It is however unfortunate that we didn.t catch this in the ballot review. > > - Nicolas. > > On 7/20/09 1:50 PM, "Ed Seidewitz" wrote: > Steve . > > Would it be better to submit a new issue and make the resolution for > that, since, technically, we have already resolved 7364? > > -- Ed > > > From: Steve Cook [mailto:Steve.Cook@microsoft.com ] > Sent: Monday, July 20, 2009 4:20 PM > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > I suggest that tomorrow I formulate a revised resolution for 7364 > and put it into ballot 9 for a vote. > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com ] > Sent: 20 July 2009 19:40 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is the only one I am hesistant to introduce editorial > changes for, just because of the amount of "copying down" I have to > do in both the metamodel and the spec doc. > > Also, I am not aware of any other situation where we had to "copy > down" featurs, constrants..with their details, , other than > introducing similary named Types as merge increments (can someone > point me to examples?) > > The other alternative is to > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 11:19 AM > [image removed] To [image removed] > Maged Elaasar/Ottawa/IBM@IBMCA > [image removed] cc [image removed] > "uml2-rtf@omg.org" > [image removed] Subject [image removed] > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > My own views on this inline. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com ] > Sent: 20 July 2009 16:08 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, this is what I had to copy into BasicComponents to make the > OCL derivation of Connector::kind parse: > > result = > if end->exists( > role.oclIsKindOf(Port) > and partWithPort->isEmpty() > and not role.oclAsType(Port).isBehavior) > then ConnectorKind::delegation > else ConnectorKind::assembly > endif > > [image removed] > > My questions: > > 1) I know we introduced merge increments before by introducing > similarly named Classes, but did we "copy down" attributes, > associations...etc from the original Class? > > I don.t see any alternative, given the merge conventions we > are using. > > 2) If we copied down stuff, did we copy all their constraints, > subsetting...etc? In the set I copied here, there are a bunch of > subsetting, constraints...etc like derivation for > ConnectableElement::end and constraints on ConnectorEnd::partWithPort > > Since there is no way not to have that stuff in the end > result because of the merge rules, I don.t see why we would need to > include it. > > 3) If we copied down stuff, don't we also have to copy down their > subclauses, i.e. in this case introduce 4 new subclauses under 8.3 > with copy down of various sections > > That.s a matter of spec convention about which I am no > expert. I just think in general that redundancy is bad, so why > introduce it? > > 4) If we copied down stuff, doesn't this introduce a maintainnce problem? > > Yes: but the problem would not exist if we implemented the > package merges properly! The original point of package merge was to > remove redundancy, not to add it. > > 5) Is this an editorial change? > > I don.t know. > > > > Thanks, > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/20/2009 10:17 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > The reason I didn.t suggest moving stuff to chapter 9 in the > original resolution is because (1) it involves significant re- > organization, and (2) a Connector has a .contract. in Components > that it doesn.t have in InternalStructures, and there is text in > chapter 8 that talks about this. I definitely don.t think we could > do all this as an editorial change. > > I think that the copying solution just needs ConnectorEnd and > Property with the partWithPort and ends associations added to figure > 8.3 (assuming the OCL can refer to the type Port without having to > copy that as well). > > -- Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 20 July 2009 15:00 > To: Maged Elaasar > Cc: Steve Cook; uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Actually this might not work as the derivation of 'kind' also refers > to Ports::ConnectorEnd.partwithPort, which would not be avaiable in > InternalStructures. > > My only concern about the copying solution is how much I have to > copy to bring all what is needed for the derivation, and whether > this can pass as editorial change since it could mean introducing > whole new subclases. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM > To > Steve Cook > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Steve, > > Given that Connector::kind's derivation dependency on internal > structures, doesn't it make more sense to move/merge Connector and > ConnectorEnd from BasicComponents to InternalStructures? > > Another reason is that Connector is not referenced by any other > Class in BasicComponents. Look at figures 8.2 and 8.3 > > Opinions? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 12:41 PM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Ok. Given this and Jim.s email it seems that we have a convention > about merges which is different from what I understood. > > With regard to Connector::end, I guess the solution is to copy > ConnectorEnd down into BasicComponents, as well as the containment > relationship. Given the merge semantics, that is a completely neutral change. > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 17 July 2009 16:36 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Components) > > Steve, > > This is not what I understand about the package merge relationships. > > My understanding is that if we have two packages P1 and P2, where P1 > has a package merge to P2, then class P1::C1 does not have direct > access to properties in P2::C1, but it needs to "copy" them in order > to be able to access them. > > This is similar I think to a Class having an InterfaceRealization to > an Interface. The class does not have access to the interface's > properties unless it "copies" them down, i.e. have ones with similarsignature. > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 10:38 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I disagree. > > You say (in your other email): .Since the spec sections are > documenting things "before" the merge .... > > Here.s figure 8.1 from the spec (hopefully the email system will > transfer this): > > [image removed] > > This states clearly that PackagingComponents merges BasicComponents, > and so on. This has nothing to do with L1, L2, L3 etc: it is the > normative specification of PackagingComponents. Similarly, > BasicComponents merges StructuredClasses. According to the extensive > explanation in chapter 7, this definitely does mean that the merge > happens here. So it is not true that .The spec suggests that there > is BasicComponents::Connector merges with InternalStructures:: > Connector in some merge level.. These merges are not suggestions > about some merge level, they are definitive (normative) statements > about the definition of these actual packages, and are also > represented in the XMI for UML http://www.omg . > org/spec/UML/20080501/Superstructure.xmi . > org/spec/UML/20080501/Superstructure.xmi> . > > - -Steve > > > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] > Sent: 17 July 2009 15:23 > To: Steve Cook > Cc: uml2-rtf@omg.org > Subject: RE: resolution 7364 from ballot 8 (Componnts) > > Steve, The spec suggests that there is BasicComponents::Connector > merges with InternalStructures::Connector in some merge level. It > does not mean that the BasicComponents::Connector class is the > result of this merge, and hence it cannot assume access to features > of that Class. Imagine the case when this class merges with > something else, then the assumption of haing access to the features > of a particular merged_with Class is not valid. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Steve Cook > > Steve Cook 07/17/2009 05:30 AM > To > Maged Elaasar/Ottawa/IBM@IBMCA > cc > "uml2-rtf@omg.org" > Subject > RE: resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > Maged > > I must be misunderstanding something. > > You say .The property is available in InternalStructures::Connector > but BasicComponents::Connector merges with that class.. > > Section 7.3.40 says .a package merge can be viewed as an operation > that takes the contents of two packages and produces a new package > that combines the contents of the packages involved in the merge. > > How can this not mean that Connector::end is available in > BasicComponents::Connector? > > -- Steve > > From: Maged Elaasar [mailto:melaasar@ca.ibm.com > > ] < br> > Sent: 17 July 2009 03:38 > To: Maged Elaasar > Cc: uml2-rtf@omg.org > Subject: Re: resolution 7364 from ballot 8 (Components) > > Another problem with this resolution. The OCL for derivation of > "kind" refers to the "Connector::end" property and gives parse error > as this property is not available in BasicComponents::Connector. > > The property is available in InternalStructures::Connector but > BasicComponents::Connector merges with that class and does not have > a generalization to it (it actually does not have any generalization) > > How do I address this? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [image removed] Maged Elaasar/Ottawa/IBM@IBMCA > > Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM > To > uml2-rtf@omg.org > cc [image removed] > Subject > resolution 7364 from ballot 8 (Components) > > > [image removed] [image removed] > > > The resolution is making Connector::kind a derived property. > Currently the metamodel has the multiplicity of this property as > [0..1]. Is this the desired multiplicity after making this property > derived? Wouldn't it be [1]? > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 [image removed] pic03461.gif Subject: RE: resolution 7364 from ballot 8 (Components) Date: Tue, 21 Jul 2009 14:26:46 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: resolution 7364 from ballot 8 (Components) thread-index: AcoKJVnmgtDRby+cRN+YENDxmZK6LAAAa48VAAI/gQA= From: "Ed Seidewitz" To: "Rouquette, Nicolas F (316A)" Cc: Nicolas -- In the metamodel, look at InternalStructures::Classifier. It is there because of the fact that InternalStructures::Property adds specific content . i.e., a generalization to ConnectableElement. So, when StructuredClassifier::ownedAttribute subsets Classifier::attribute, the intent of this particular merge increment was that the relevant parts of Classifier and Classifier::property would be copied down from Kernel in InternalStructures. [EVS] I don.t see why you would need a merge increment for Classifier in InternalStructures for this. You get this effect automatically when InternalStructures::Property is merged with Kernel::Property (and there is no Classifier::property, only Classifier::attribute). And, in any case, if there InternalStructures::Classifier was in the model per Figure 9.2, InternalStructures::Classifier::attribute would have no relationship to Kernel::Classifier::attribute before the merge, and it is only the latter that is being subsetted by StructuredClassifier::attribute. So, I agree with Bran that Figure 9.2 seems to be in error. -- Ed Subject: RE: resolution 7364 from ballot 8 (Components) Date: Tue, 21 Jul 2009 14:40:17 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: resolution 7364 from ballot 8 (Components) thread-index: AcoKMHidK8zlFmajTrK5LBhyxMKIPAAAX9Pw From: "Ed Seidewitz" To: "Maged Elaasar" Cc: "Rouquette, Nicolas F (316A)" , Maged -- Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property [EVS] Actually, it subsets Kernel::Classifier:attribute. There is no Kernel::Classifier::property . so I will just assume you mean Kernel::Classifier::attribute in the following. 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. [EVS] Good point! (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. [EVS] OK, now I understand.and I agree with that the above proposed changes are necessary. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. [EVS] Yes, I think you are right here, too. But this really does need to be a new issue. This package merge stuff really makes my head hurt (and I thought figuring out the action semantics was bad enough!). -- Ed Subject: RE: resolution 7364 from ballot 8 (Components) To: "Ed Seidewitz" Cc: "Rouquette, Nicolas F (316A)" , uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Tue, 21 Jul 2009 14:59:10 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/21/2009 14:59:21 Ok looks like we need a new issue to docuement the inconsistency discovered below. Jeurgen, can you please open one taking the thread below as text? Now, that this is sorted out, it appears that we indeed had a precedence where we had to "copy down" structure (in this case we copied Kernel::Classifier::attribute down to InternalStructures::Classifier), although we did not "document" it properly, leading to the confusion. Now, in the new case of having to "copy down", I guess we need to document this more, by having proper subclauses that references the others by (see xxx for details). What I am not sure about is the level of copy vs. reference in the text. For example, part of what I have to copy in the metamodel is a derived association that has a derivation and constraints...etc. Do I copy those? All in all, I think since we are setting a precedence in this "copy down" documentation, we better do it carefully through a new issue resolution that we review. Steve, can you prepare such a resolution? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/21/2009 02:40 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Subject RE: resolution 7364 from ballot 8 (Components) Maged -- Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property [EVS] Actually, it subsets Kernel::Classifier:attribute. There is no Kernel::Classifier::property . so I will just assume you mean Kernel::Classifier::attribute in the following. 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. [EVS] Good point! (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. [EVS] OK, now I understand.and I agree with that the above proposed changes are necessary. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. [EVS] Yes, I think you are right here, too. But this really does need to be a new issue. This package merge stuff really makes my head hurt (and I thought figuring out the action semantics was bad enough!). -- Ed pic09179.gif From: "Rouquette, Nicolas F (316A)" To: Maged Elaasar , Ed Seidewitz CC: "uml2-rtf@omg.org" Date: Tue, 21 Jul 2009 12:03:53 -0700 Subject: Re: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoKNV1tgzeitpU1Sm+Y1Fm/pOBruQAAJ+3n Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Please note that the changes I indicated below for InternalStructures::Classifier are necessary only because this metaclass has been copied down in this package. As Bran and I have pointed out earlier, copying Kernel::Classifier in InternalStructures::Classifier isn.t necessary because nothing is added/modified and because none of the OCL in InternalStructures makes reference to Classifier or to Classifier::attribute. In 7364, we need to do the copy not because we.re modifying anything but because we are referencing them in the OCL for /Connector::kind. - Nicolas. On 7/21/09 11:59 AM, "Maged Elaasar" wrote: Ok looks like we need a new issue to docuement the inconsistency discovered below. Jeurgen, can you please open one taking the thread below as text? Now, that this is sorted out, it appears that we indeed had a precedence where we had to "copy down" structure (in this case we copied Kernel::Classifier::attribute down to InternalStructures::Classifier), although we did not "document" it properly, leading to the confusion. Now, in the new case of having to "copy down", I guess we need to document this more, by having proper subclauses that references the others by (see xxx for details). What I am not sure about is the level of copy vs. reference in the text. For example, part of what I have to copy in the metamodel is a derived association that has a derivation and constraints...etc. Do I copy those? All in all, I think since we are setting a precedence in this "copy down" documentation, we better do it carefully through a new issue resolution that we review. Steve, can you prepare such a resolution? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/21/2009 02:40 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Subject RE: resolution 7364 from ballot 8 (Components) Maged -- Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property [EVS] Actually, it subsets Kernel::Classifier:attribute. There is no Kernel::Classifier::property . so I will just assume you mean Kernel::Classifier::attribute in the following. 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. [EVS] Good point! (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. [EVS] OK, now I understand.and I agree with that the above proposed changes are necessary. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. [EVS] Yes, I think you are right here, too. But this really does need to be a new issue. This package merge stuff really makes my head hurt (and I thought figuring out the action semantics was bad enough!). -- Ed Subject: Re: resolution 7364 from ballot 8 (Components) To: "Rouquette, Nicolas F (316A)" Cc: Ed Seidewitz , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Tue, 21 Jul 2009 15:13:12 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/21/2009 15:13:03 > As Bran and I have pointed out earlier, copying Kernel::Classifier > in InternalStructures::Classifier isn.t necessary because nothing is > added/modified and because none of the OCL in InternalStructures > makes reference to Classifier or to Classifier::attribute. > the reason the copying was "necessary" here is to make StructuredClassifier::ownedAttribute subsetting "valid" (by type conformance) > In 7364, we need to do the copy not because we.re modifying anything > but because we are referencing them in the OCL for /Connector::kind. The reason the copying here is "necessary" is to make the OCL constraint parse fine. From: "Rouquette, Nicolas F (316A)" To: Maged Elaasar CC: Ed Seidewitz , "uml2-rtf@omg.org" Date: Tue, 21 Jul 2009 13:23:59 -0700 Subject: Re: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoKN1aoxIrOMHw0TGOuMvur06q7MQACdcU3 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Maged, Just to be 100% clear: You could delete InternalStructures::Classifier in the current metamodel without affecting its validity or the specification document at all. With or without, it is still perfectly valid to have: InternalStructures::StructuredClassifier specialize Kernel::Classifier InternalStructures::StructuredClassifier::ownedAttribute to subset InternalStructures::StructuredClassifier::role, Kernel::Classifier::attribute and Kernel::Namespace::ownedMember You were asking whether there is a precedent in the current metamodel for copying classifiers/features to justify 14041. InternalStructures::Classifier is the only precedent I found but it is clear that this is a weak precedent since there is no need whatsoever for this element to be there in UML 2.2. - Nicolas. On 7/21/09 12:13 PM, "Maged Elaasar" wrote: > As Bran and I have pointed out earlier, copying Kernel::Classifier > in InternalStructures::Classifier isn.t necessary because nothing is > added/modified and because none of the OCL in InternalStructures > makes reference to Classifier or to Classifier::attribute. > the reason the copying was "necessary" here is to make StructuredClassifier::ownedAttribute subsetting "valid" (by type conformance) > In 7364, we need to do the copy not because we.re modifying anything > but because we are referencing them in the OCL for /Connector::kind. The reason the copying here is "necessary" is to make the OCL constraint parse fine. Subject: RE: resolution 7364 from ballot 8 (Components) Date: Tue, 21 Jul 2009 16:40:14 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: resolution 7364 from ballot 8 (Components) thread-index: AcoKN1aoxIrOMHw0TGOuMvur06q7MQACdcU3AABXafA= From: "Ed Seidewitz" To: "Rouquette, Nicolas F (316A)" Cc: Nicolas . You are right that you could delete InternalStructure::Classifier from the current metamodel without affecting its validity. As Maged pointed out, the metamodel would actually be invalid in either case! Kernel::Classifier::attribute has the type Kernel::Property, while InternalStructures::StructuredClassifier::ownedAttribute has the type InternalStructures::Property which is not Kernel::Property or a subclass of it. Therefore, InternalStructures::StructuredClassifier::ownedAttribute cannot subset Kernel::Classifier::attribute (at least not in the unmerged model). Making InternalStructures::StructuredClassifier a subclass of InternalStructures::Classifier would resolve this. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, July 21, 2009 4:24 PM To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Maged, Just to be 100% clear: You could delete InternalStructures::Classifier in the current metamodel without affecting its validity or the specification document at all. With or without, it is still perfectly valid to have: InternalStructures::StructuredClassifier specialize Kernel::Classifier InternalStructures::StructuredClassifier::ownedAttribute to subset InternalStructures::StructuredClassifier::role, Kernel::Classifier::attribute and Kernel::Namespace::ownedMember You were asking whether there is a precedent in the current metamodel for copying classifiers/features to justify 14041. InternalStructures::Classifier is the only precedent I found but it is clear that this is a weak precedent since there is no need whatsoever for this element to be there in UML 2.2. - Nicolas. On 7/21/09 12:13 PM, "Maged Elaasar" wrote: > As Bran and I have pointed out earlier, copying Kernel::Classifier > in InternalStructures::Classifier isn.t necessary because nothing is > added/modified and because none of the OCL in InternalStructures > makes reference to Classifier or to Classifier::attribute. > the reason the copying was "necessary" here is to make StructuredClassifier::ownedAttribute subsetting "valid" (by type conformance) > In 7364, we need to do the copy not because we.re modifying anything > but because we are referencing them in the OCL for /Connector::kind. The reason the copying here is "necessary" is to make the OCL constraint parse fine. From: "Rouquette, Nicolas F (316A)" To: Ed Seidewitz CC: "uml2-rtf@omg.org" Date: Tue, 21 Jul 2009 14:17:48 -0700 Subject: Re: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoKN1aoxIrOMHw0TGOuMvur06q7MQACdcU3AABXafAAAYm/PA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Ed, Mea culpa: if you change InternalStructures::StructuredClassifier::ownedAttribute to be Kernel::Property, then we can safely delete InternalStructures::Classifier. The metamodel is consistent in either case. Bran.s addition of InternalStructure::Classifier doesn.t change anything at all as far as the semantics of package merge: .In terms of model semantics, there is no difference between a model with explicit package merges, and a model in which all the merges have been performed.. As I said before, the catch is that as far as OCL constraints are concerned, then it is definitely advisable to make sure that OCL constraints are well formed in the context of the receiving package as well as that of the resulting package because very few people and no tools that I know of provide support for well-formedness checking from the perspective of the resulting package rather than that of the receiving package which is what users see in diagrams & the browser of a modeling tool. - Nicolas. On 7/21/09 1:40 PM, "Ed Seidewitz" wrote: Nicolas . You are right that you could delete InternalStructure::Classifier from the current metamodel without affecting its validity. As Maged pointed out, the metamodel would actually be invalid in either case! Kernel::Classifier::attribute has the type Kernel::Property, while InternalStructures::StructuredClassifier::ownedAttribute has the type InternalStructures::Property which is not Kernel::Property or a subclass of it. Therefore, InternalStructures::StructuredClassifier::ownedAttribute cannot subset Kernel::Classifier::attribute (at least not in the unmerged model). Making InternalStructures::StructuredClassifier a subclass of InternalStructures::Classifier would resolve this. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, July 21, 2009 4:24 PM To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Maged, Just to be 100% clear: You could delete InternalStructures::Classifier in the current metamodel without affecting its validity or the specification document at all. With or without, it is still perfectly valid to have: InternalStructures::StructuredClassifier specialize Kernel::Classifier InternalStructures::StructuredClassifier::ownedAttribute to subset InternalStructures::StructuredClassifier::role, Kernel::Classifier::attribute and Kernel::Namespace::ownedMember You were asking whether there is a precedent in the current metamodel for copying classifiers/features to justify 14041. InternalStructures::Classifier is the only precedent I found but it is clear that this is a weak precedent since there is no need whatsoever for this element to be there in UML 2.2. - Nicolas. On 7/21/09 12:13 PM, "Maged Elaasar" wrote: > As Bran and I have pointed out earlier, copying Kernel::Classifier > in InternalStructures::Classifier isn.t necessary because nothing is > added/modified and because none of the OCL in InternalStructures > makes reference to Classifier or to Classifier::attribute. > the reason the copying was "necessary" here is to make StructuredClassifier::ownedAttribute subsetting "valid" (by type conformance) > In 7364, we need to do the copy not because we.re modifying anything > but because we are referencing them in the OCL for /Connector::kind. The reason the copying here is "necessary" is to make the OCL constraint parse fine. Subject: RE: resolution 7364 from ballot 8 (Components) Date: Tue, 21 Jul 2009 17:40:42 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: resolution 7364 from ballot 8 (Components) thread-index: AcoKN1aoxIrOMHw0TGOuMvur06q7MQACdcU3AABXafAAAYm/PAAAvJEg From: "Ed Seidewitz" To: "Rouquette, Nicolas F (316A)" Cc: Nicolas . But EncapsulatedClassifier::ownedPort subsets StructuredClassifier::ownedAttribute, and Ports::Port is a subclass of InternalStructures::Property, not Kernel::Property, at least in the unmerged model. So one would expect StructuredClassifier::ownedAttribute to have type InternalStructures::Property. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, July 21, 2009 5:18 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Ed, Mea culpa: if you change InternalStructures::StructuredClassifier::ownedAttribute to be Kernel::Property, then we can safely delete InternalStructures::Classifier. The metamodel is consistent in either case. Bran.s addition of InternalStructure::Classifier doesn.t change anything at all as far as the semantics of package merge: .In terms of model semantics, there is no difference between a model with explicit package merges, and a model in which all the merges have been performed.. As I said before, the catch is that as far as OCL constraints are concerned, then it is definitely advisable to make sure that OCL constraints are well formed in the context of the receiving package as well as that of the resulting package because very few people and no tools that I know of provide support for well-formedness checking from the perspective of the resulting package rather than that of the receiving package which is what users see in diagrams & the browser of a modeling tool. - Nicolas. On 7/21/09 1:40 PM, "Ed Seidewitz" wrote: Nicolas . You are right that you could delete InternalStructure::Classifier from the current metamodel without affecting its validity. As Maged pointed out, the metamodel would actually be invalid in either case! Kernel::Classifier::attribute has the type Kernel::Property, while InternalStructures::StructuredClassifier::ownedAttribute has the type InternalStructures::Property which is not Kernel::Property or a subclass of it. Therefore, InternalStructures::StructuredClassifier::ownedAttribute cannot subset Kernel::Classifier::attribute (at least not in the unmerged model). Making InternalStructures::StructuredClassifier a subclass of InternalStructures::Classifier would resolve this. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, July 21, 2009 4:24 PM To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Maged, Just to be 100% clear: You could delete InternalStructures::Classifier in the current metamodel without affecting its validity or the specification document at all. With or without, it is still perfectly valid to have: InternalStructures::StructuredClassifier specialize Kernel::Classifier InternalStructures::StructuredClassifier::ownedAttribute to subset InternalStructures::StructuredClassifier::role, Kernel::Classifier::attribute and Kernel::Namespace::ownedMember You were asking whether there is a precedent in the current metamodel for copying classifiers/features to justify 14041. InternalStructures::Classifier is the only precedent I found but it is clear that this is a weak precedent since there is no need whatsoever for this element to be there in UML 2.2. - Nicolas. On 7/21/09 12:13 PM, "Maged Elaasar" wrote: > As Bran and I have pointed out earlier, copying Kernel::Classifier > in InternalStructures::Classifier isn.t necessary because nothing is > added/modified and because none of the OCL in InternalStructures > makes reference to Classifier or to Classifier::attribute. > the reason the copying was "necessary" here is to make StructuredClassifier::ownedAttribute subsetting "valid" (by type conformance) > In 7364, we need to do the copy not because we.re modifying anything > but because we are referencing them in the OCL for /Connector::kind. The reason the copying here is "necessary" is to make the OCL constraint parse fine. From: "Rouquette, Nicolas F (316A)" To: Ed Seidewitz CC: "uml2-rtf@omg.org" Date: Tue, 21 Jul 2009 15:23:21 -0700 Subject: Re: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoKN1aoxIrOMHw0TGOuMvur06q7MQACdcU3AABXafAAAYm/PAAAvJEgAAGNfwg= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Ed, This expectation is reasonable but it is only a convention. I repeat: the unmerged metamodel will be perfectly kosher w.r.t. The golden rules of package merge with our without InternalStructures::Classifier. Changing the references to be consistent with local copies of classifiers/features is only a convention that facilitates reading/reviewing the metamodel. At the end of the day, the only thing that matters is the normative model semantics of package merge. OCL is a different matter; for the OCL specification says nothing about name resolution in the context of the receiving vs. resulting package. In that case, the wise and safest thing to do is to make sure that OCL constraints are well formed in both contexts and this is a reasonable justification for making local copies of classifiers/features but this justification should never be construed as a necessity unless one is particularly interested in doing OCL checking in the context of the receiving package as distinct from that of the resulting package. For well-formed models, the two are equivalent. For ill-formed models, they are different since there is no well-formed receiving package to speak of. Note that to appreciate this fine distinction, it is necessary to have an OCL implementation which exposes the capability to bind OCL to a given model or metamodel. As far as I know, there are only two OCL engines capable of doing this: Eclipse MDT OCL and Dresden OCL2. However, some tools hide this flexibilty and users are forced to work with only one binding, e.g., an implementation of the UML2 metamodel. - Nicolas. On 7/21/09 2:40 PM, "Ed Seidewitz" wrote: Nicolas . But EncapsulatedClassifier::ownedPort subsets StructuredClassifier::ownedAttribute, and Ports::Port is a subclass of InternalStructures::Property, not Kernel::Property, at least in the unmerged model. So one would expect StructuredClassifier::ownedAttribute to have type InternalStructures::Property. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, July 21, 2009 5:18 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Ed, Mea culpa: if you change InternalStructures::StructuredClassifier::ownedAttribute to be Kernel::Property, then we can safely delete InternalStructures::Classifier. The metamodel is consistent in either case. Bran.s addition of InternalStructure::Classifier doesn.t change anything at all as far as the semantics of package merge: .In terms of model semantics, there is no difference between a model with explicit package merges, and a model in which all the merges have been performed.. As I said before, the catch is that as far as OCL constraints are concerned, then it is definitely advisable to make sure that OCL constraints are well formed in the context of the receiving package as well as that of the resulting package because very few people and no tools that I know of provide support for well-formedness checking from the perspective of the resulting package rather than that of the receiving package which is what users see in diagrams & the browser of a modeling tool. - Nicolas. On 7/21/09 1:40 PM, "Ed Seidewitz" wrote: Nicolas . You are right that you could delete InternalStructure::Classifier from the current metamodel without affecting its validity. As Maged pointed out, the metamodel would actually be invalid in either case! Kernel::Classifier::attribute has the type Kernel::Property, while InternalStructures::StructuredClassifier::ownedAttribute has the type InternalStructures::Property which is not Kernel::Property or a subclass of it. Therefore, InternalStructures::StructuredClassifier::ownedAttribute cannot subset Kernel::Classifier::attribute (at least not in the unmerged model). Making InternalStructures::StructuredClassifier a subclass of InternalStructures::Classifier would resolve this. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, July 21, 2009 4:24 PM To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Maged, Just to be 100% clear: You could delete InternalStructures::Classifier in the current metamodel without affecting its validity or the specification document at all. With or without, it is still perfectly valid to have: InternalStructures::StructuredClassifier specialize Kernel::Classifier InternalStructures::StructuredClassifier::ownedAttribute to subset InternalStructures::StructuredClassifier::role, Kernel::Classifier::attribute and Kernel::Namespace::ownedMember You were asking whether there is a precedent in the current metamodel for copying classifiers/features to justify 14041. InternalStructures::Classifier is the only precedent I found but it is clear that this is a weak precedent since there is no need whatsoever for this element to be there in UML 2.2. - Nicolas. On 7/21/09 12:13 PM, "Maged Elaasar" wrote: > As Bran and I have pointed out earlier, copying Kernel::Classifier > in InternalStructures::Classifier isn.t necessary because nothing is > added/modified and because none of the OCL in InternalStructures > makes reference to Classifier or to Classifier::attribute. > the reason the copying was "necessary" here is to make StructuredClassifier::ownedAttribute subsetting "valid" (by type conformance) > In 7364, we need to do the copy not because we.re modifying anything > but because we are referencing them in the OCL for /Connector::kind. The reason the copying here is "necessary" is to make the OCL constraint parse fine. From: Steve Cook To: Maged Elaasar , Ed Seidewitz CC: "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" , "issues@omg.org" Date: Wed, 22 Jul 2009 10:15:32 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoKNdwp1tA8pgYvQEOtE7SWU3EiCAAdjLow Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US First, I.m copying the thread to issues@omg.org because you.ve asked Juergen for a new issue number. I think the title of the issue should be .Need to copy down merged content to make constraints valid in receiving package.. Juergen, can we have a number urgently please? Yes, I will draft a resolution to it. I will propose changes on the basis that 7364 is accepted, and I will also propose changes to chapter 9 to reflect the discussion in this thread. I will try to do it before the end of the week. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 19:59 To: Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Ok looks like we need a new issue to docuement the inconsistency discovered below. Jeurgen, can you please open one taking the thread below as text? Now, that this is sorted out, it appears that we indeed had a precedence where we had to "copy down" structure (in this case we copied Kernel::Classifier::attribute down to InternalStructures::Classifier), although we did not "document" it properly, leading to the confusion. Now, in the new case of having to "copy down", I guess we need to document this more, by having proper subclauses that references the others by (see xxx for details). What I am not sure about is the level of copy vs. reference in the text. For example, part of what I have to copy in the metamodel is a derived association that has a derivation and constraints...etc. Do I copy those? All in all, I think since we are setting a precedence in this "copy down" documentation, we better do it carefully through a new issue resolution that we review. Steve, can you prepare such a resolution? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/21/2009 02:40 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Subject RE: resolution 7364 from ballot 8 (Components) Maged -- Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property [EVS] Actually, it subsets Kernel::Classifier:attribute. There is no Kernel::Classifier::property . so I will just assume you mean Kernel::Classifier::attribute in the following. 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. [EVS] Good point! (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. [EVS] OK, now I understand.and I agree with that the above proposed changes are necessary. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. [EVS] Yes, I think you are right here, too. But this really does need to be a new issue. This package merge stuff really makes my head hurt (and I thought figuring out the action semantics was bad enough!). -- Ed From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Date: Wed, 22 Jul 2009 11:10:57 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoJTAa6Lk1w3k/sQE6isSZhIOIbvgBZ3f2A Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Maged, I am still not clear why you had to copy all this stuff. I can understand that you had to copy the end association in order for the local merge increment of Connector to have a well-defined end property. But why could you not refer directly to Ports::ConnectorEnd, in exactly the same way as contract refers to BasicBehaviors::Behavior? If you did, surely the following ought to work? result = if end->exists( role.oclIsKindOf(Ports::Port) and partWithPort->isEmpty() and not role.oclAsType(Ports::Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 16:08 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections 4) If we copied down stuff, doesn't this introduce a maintainnce problem? 5) Is this an editorial change? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: resolution 7364 from ballot 8 (Components) To: Steve Cook Cc: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 22 Jul 2009 10:34:07 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/22/2009 10:34:08 Steve, The problem is that "partWithPort" comes from Ports::ConnectorEnd not from InternalStructures::ConnectorEnd, so you need kind of a merge of the two. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/22/2009 06:10 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged, I am still not clear why you had to copy all this stuff. I can understand that you had to copy the end association in order for the local merge increment of Connector to have a well-defined end property. But why could you not refer directly to Ports::ConnectorEnd, in exactly the same way as contract refers to BasicBehaviors::Behavior? If you did, surely the following ought to work? result = if end->exists( role.oclIsKindOf(Ports::Port) and partWithPort->isEmpty() and not role.oclAsType(Ports::Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 16:08 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections 4) If we copied down stuff, doesn't this introduce a maintainnce problem? 5) Is this an editorial change? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic28735.gif Subject: RE: resolution 7364 from ballot 8 (Components) To: Maged Elaasar Cc: Steve Cook , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 22 Jul 2009 10:36:56 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/22/2009 10:36:56 I meant to say: "The problem is that "partWithPort" comes from Ports::ConnectorEnd while "role" comes from InternalStructures::ConnectorEnd..." Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 07/22/2009 10:34 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, The problem is that "partWithPort" comes from Ports::ConnectorEnd not from InternalStructures::ConnectorEnd, so you need kind of a merge of the two. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/22/2009 06:10 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged, I am still not clear why you had to copy all this stuff. I can understand that you had to copy the end association in order for the local merge increment of Connector to have a well-defined end property. But why could you not refer directly to Ports::ConnectorEnd, in exactly the same way as contract refers to BasicBehaviors::Behavior? If you did, surely the following ought to work? result = if end->exists( role.oclIsKindOf(Ports::Port) and partWithPort->isEmpty() and not role.oclAsType(Ports::Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 16:08 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections 4) If we copied down stuff, doesn't this introduce a maintainnce problem? 5) Is this an editorial change? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic00638.gif pic08606.gif From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Date: Wed, 22 Jul 2009 16:46:57 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoK2qS2mN8igmVqTCijmW/D2xfxcQACLmhw Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Oh I see. Yes. Why do you need to copy down Port, though? From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 22 July 2009 15:37 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) I meant to say: "The problem is that "partWithPort" comes from Ports::ConnectorEnd while "role" comes from InternalStructures::ConnectorEnd..." Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 07/22/2009 10:34 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, The problem is that "partWithPort" comes from Ports::ConnectorEnd not from InternalStructures::ConnectorEnd, so you need kind of a merge of the two. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/22/2009 06:10 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged, I am still not clear why you had to copy all this stuff. I can understand that you had to copy the end association in order for the local merge increment of Connector to have a well-defined end property. But why could you not refer directly to Ports::ConnectorEnd, in exactly the same way as contract refers to BasicBehaviors::Behavior? If you did, surely the following ought to work? result = if end->exists( role.oclIsKindOf(Ports::Port) and partWithPort->isEmpty() and not role.oclAsType(Ports::Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 16:08 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections 4) If we copied down stuff, doesn't this introduce a maintainnce problem? 5) Is this an editorial change? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: resolution 7364 from ballot 8 (Components) To: Steve Cook Cc: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 22 Jul 2009 13:28:43 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/22/2009 13:28:44 However, I managed to minize the copy down as shown in red in the figure below: - the only other thing is a PackageImport from BasicComponents to Ports, to get the "Port" type in the OCL to be recognized (I could have done it too with an ElementImport, is there a preference?). Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/22/2009 11:46 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Oh I see. Yes. Why do you need to copy down Port, though? From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 22 July 2009 15:37 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) I meant to say: "The problem is that "partWithPort" comes from Ports::ConnectorEnd while "role" comes from InternalStructures::ConnectorEnd..." Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 07/22/2009 10:34 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, The problem is that "partWithPort" comes from Ports::ConnectorEnd not from InternalStructures::ConnectorEnd, so you need kind of a merge of the two. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/22/2009 06:10 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged, I am still not clear why you had to copy all this stuff. I can understand that you had to copy the end association in order for the local merge increment of Connector to have a well-defined end property. But why could you not refer directly to Ports::ConnectorEnd, in exactly the same way as contract refers to BasicBehaviors::Behavior? If you did, surely the following ought to work? result = if end->exists( role.oclIsKindOf(Ports::Port) and partWithPort->isEmpty() and not role.oclAsType(Ports::Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 16:08 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections 4) If we copied down stuff, doesn't this introduce a maintainnce problem? 5) Is this an editorial change? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic21728.gif From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Date: Wed, 22 Jul 2009 20:29:24 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoK8eNtVSDYPPRgSRG7yYDJYBtgagAEIpcA Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Great stuff on the minimized copying . I will formulate a new resolution on that basis. >- the only other thing is a PackageImport from BasicComponents to Ports, to get the "Port" type in the OCL to be recognized (I could have done it too with an ElementImport, is there a preference?). Of course that is another conflict between what UML says its semantics are, and how we are using it to define itself. According to UML semantics, you should be able to access Port using its fully-qualified name without any import. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 22 July 2009 18:29 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) However, I managed to minize the copy down as shown in red in the figure below: - the only other thing is a PackageImport from BasicComponents to Ports, to get the "Port" type in the OCL to be recognized (I could have done it too with an ElementImport, is there a preference?). Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/22/2009 11:46 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Oh I see. Yes. Why do you need to copy down Port, though? From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 22 July 2009 15:37 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) I meant to say: "The problem is that "partWithPort" comes from Ports::ConnectorEnd while "role" comes from InternalStructures::ConnectorEnd..." Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 07/22/2009 10:34 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, The problem is that "partWithPort" comes from Ports::ConnectorEnd not from InternalStructures::ConnectorEnd, so you need kind of a merge of the two. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/22/2009 06:10 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged, I am still not clear why you had to copy all this stuff. I can understand that you had to copy the end association in order for the local merge increment of Connector to have a well-defined end property. But why could you not refer directly to Ports::ConnectorEnd, in exactly the same way as contract refers to BasicBehaviors::Behavior? If you did, surely the following ought to work? result = if end->exists( role.oclIsKindOf(Ports::Port) and partWithPort->isEmpty() and not role.oclAsType(Ports::Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif Thanks -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 16:08 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, this is what I had to copy into BasicComponents to make the OCL derivation of Connector::kind parse: result = if end->exists( role.oclIsKindOf(Port) and partWithPort->isEmpty() and not role.oclAsType(Port).isBehavior) then ConnectorKind::delegation else ConnectorKind::assembly endif My questions: 1) I know we introduced merge increments before by introducing similarly named Classes, but did we "copy down" attributes, associations...etc from the original Class? 2) If we copied down stuff, did we copy all their constraints, subsetting...etc? In the set I copied here, there are a bunch of subsetting, constraints...etc like derivation for ConnectableElement::end and constraints on ConnectorEnd::partWithPort 3) If we copied down stuff, don't we also have to copy down their subclauses, i.e. in this case introduce 4 new subclauses under 8.3 with copy down of various sections 4) If we copied down stuff, doesn't this introduce a maintainnce problem? 5) Is this an editorial change? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/20/2009 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged The reason I didn.t suggest moving stuff to chapter 9 in the original resolution is because (1) it involves significant re-organization, and (2) a Connector has a .contract. in Components that it doesn.t have in InternalStructures, and there is text in chapter 8 that talks about this. I definitely don.t think we could do all this as an editorial change. I think that the copying solution just needs ConnectorEnd and Property with the partWithPort and ends associations added to figure 8.3 (assuming the OCL can refer to the type Port without having to copy that as well). -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 20 July 2009 15:00 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Actually this might not work as the derivation of 'kind' also refers to Ports::ConnectorEnd.partwithPort, which would not be avaiable in InternalStructures. My only concern about the copying solution is how much I have to copy to bring all what is needed for the derivation, and whether this can pass as editorial change since it could mean introducing whole new subclases. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/20/2009 09:46 AM To Steve Cook cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Steve, Given that Connector::kind's derivation dependency on internal structures, doesn't it make more sense to move/merge Connector and ConnectorEnd from BasicComponents to InternalStructures? Another reason is that Connector is not referenced by any other Class in BasicComponents. Look at figures 8.2 and 8.3 Opinions? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 12:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Ok. Given this and Jim.s email it seems that we have a convention about merges which is different from what I understood. With regard to Connector::end, I guess the solution is to copy ConnectorEnd down into BasicComponents, as well as the containment relationship. Given the merge semantics, that is a completely neutral change. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 16:36 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, This is not what I understand about the package merge relationships. My understanding is that if we have two packages P1 and P2, where P1 has a package merge to P2, then class P1::C1 does not have direct access to properties in P2::C1, but it needs to "copy" them in order to be able to access them. This is similar I think to a Class having an InterfaceRealization to an Interface. The class does not have access to the interface's properties unless it "copies" them down, i.e. have ones with similar signature. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 10:38 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I disagree. You say (in your other email): .Since the spec sections are documenting things "before" the merge .... Here.s figure 8.1 from the spec (hopefully the email system will transfer this): This states clearly that PackagingComponents merges BasicComponents, and so on. This has nothing to do with L1, L2, L3 etc: it is the normative specification of PackagingComponents. Similarly, BasicComponents merges StructuredClasses. According to the extensive explanation in chapter 7, this definitely does mean that the merge happens here. So it is not true that .The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level.. These merges are not suggestions about some merge level, they are definitive (normative) statements about the definition of these actual packages, and are also represented in the XMI for UML http://www.omg.org/spec/UML/20080501/Superstructure.xmi. - -Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 15:23 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Componnts) Steve, The spec suggests that there is BasicComponents::Connector merges with InternalStructures::Connector in some merge level. It does not mean that the BasicComponents::Connector class is the result of this merge, and hence it cannot assume access to features of that Class. Imagine the case when this class merges with something else, then the assumption of haing access to the features of a particular merged_with Class is not valid. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/17/2009 05:30 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Maged I must be misunderstanding something. You say .The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class.. Section 7.3.40 says .a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. How can this not mean that Connector::end is available in BasicComponents::Connector? -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 17 July 2009 03:38 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: resolution 7364 from ballot 8 (Components) Another problem with this resolution. The OCL for derivation of "kind" refers to the "Connector::end" property and gives parse error as this property is not available in BasicComponents::Connector. The property is available in InternalStructures::Connector but BasicComponents::Connector merges with that class and does not have a generalization to it (it actually does not have any generalization) How do I address this? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 07/16/2009 10:20 PM To uml2-rtf@omg.org cc Subject resolution 7364 from ballot 8 (Components) The resolution is making Connector::kind a derived property. Currently the metamodel has the multiplicity of this property as [0..1]. Is this the desired multiplicity after making this property derived? Wouldn't it be [1]? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 From: Steve Cook To: Maged Elaasar , Ed Seidewitz CC: "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Date: Thu, 23 Jul 2009 13:00:02 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoKNdwp1tA8pgYvQEOtE7SWU3EiCAAdjLowADaviRA= Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US I.m preparing this resolution (for which an issue number is still needed) and looking at the problems with InternalStructures::Classsifier. If we do as suggested, i.e. Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier, then it makes InternalStructures::StructuredClassifier::ownedAttribute legally subset InternalStructures::Classifier::attribute. So far so good. However, we then have the problem of InternalStructures::StructuredClassifier::ownedAttribute subsetting ownedMember, and similarly ownedConnector subsetting ownedMember. I believe this means that we have to also say that InternalStructures::Classifier should specialize Kernel::Namespace. Now, if you look at 9.7, you see that Collaboration::Classifier specializes RedefinableElement, Namespace and Type. I cannot see any reason why it should specialize all of these. All it actually needs is to specialize Element so it gets access to ownedElement. Hence I suggest that we have a single Generalizations clause in 9.3.2, showing that Classifier (InternalStuctures and Collaborations) specializes Kernel::Namespace, and change 9.7 so that Classifier only specializes Kernel::Namespace. Thoughts? -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 22 July 2009 10:16 To: Maged Elaasar; Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org; issues@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) First, I.m copying the thread to issues@omg.org because you.ve asked Juergen for a new issue number. I think the title of the issue should be .Need to copy down merged content to make constraints valid in receiving package.. Juergen, can we have a number urgently please? Yes, I will draft a resolution to it. I will propose changes on the basis that 7364 is accepted, and I will also propose changes to chapter 9 to reflect the discussion in this thread. I will try to do it before the end of the week. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 19:59 To: Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Ok looks like we need a new issue to docuement the inconsistency discovered below. Jeurgen, can you please open one taking the thread below as text? Now, that this is sorted out, it appears that we indeed had a precedence where we had to "copy down" structure (in this case we copied Kernel::Classifier::attribute down to InternalStructures::Classifier), although we did not "document" it properly, leading to the confusion. Now, in the new case of having to "copy down", I guess we need to document this more, by having proper subclauses that references the others by (see xxx for details). What I am not sure about is the level of copy vs. reference in the text. For example, part of what I have to copy in the metamodel is a derived association that has a derivation and constraints...etc. Do I copy those? All in all, I think since we are setting a precedence in this "copy down" documentation, we better do it carefully through a new issue resolution that we review. Steve, can you prepare such a resolution? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/21/2009 02:40 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Subject RE: resolution 7364 from ballot 8 (Components) Maged -- Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property [EVS] Actually, it subsets Kernel::Classifier:attribute. There is no Kernel::Classifier::property . so I will just assume you mean Kernel::Classifier::attribute in the following. 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. [EVS] Good point! (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. [EVS] OK, now I understand.and I agree with that the above proposed changes are necessary. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. [EVS] Yes, I think you are right here, too. But this really does need to be a new issue. This package merge stuff really makes my head hurt (and I thought figuring out the action semantics was bad enough!). -- Ed Subject: RE: resolution 7364 from ballot 8 (Components) To: Steve Cook Cc: Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 23 Jul 2009 09:44:06 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/23/2009 09:44:06 Steve, the only remaining issue would be InternalStructures::StructuredClassifier::ownedConnector subsetting Kernel::Classifier::feature Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/23/2009 08:00 AM To Maged Elaasar/Ottawa/IBM@IBMCA, Ed Seidewitz cc "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) I.m preparing this resolution (for which an issue number is still needed) and looking at the problems with InternalStructures::Classsifier. If we do as suggested, i.e. Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier, then it makes InternalStructures::StructuredClassifier::ownedAttribute legally subset InternalStructures::Classifier::attribute. So far so good. However, we then have the problem of InternalStructures::StructuredClassifier::ownedAttribute subsetting ownedMember, and similarly ownedConnector subsetting ownedMember. I believe this means that we have to also say that InternalStructures::Classifier should specialize Kernel::Namespace. Now, if you look at 9.7, you see that Collaboration::Classifier specializes RedefinableElement, Namespace and Type. I cannot see any reason why it should specialize all of these. All it actually needs is to specialize Element so it gets access to ownedElement. Hence I suggest that we have a single Generalizations clause in 9.3.2, showing that Classifier (InternalStuctures and Collaborations) specializes Kernel::Namespace, and change 9.7 so that Classifier only specializes Kernel::Namespace. Thoughts? -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 22 July 2009 10:16 To: Maged Elaasar; Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org; issues@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) First, I.m copying the thread to issues@omg.org because you.ve asked Juergen for a new issue number. I think the title of the issue should be .Need to copy down merged content to make constraints valid in receiving package.. Juergen, can we have a number urgently please? Yes, I will draft a resolution to it. I will propose changes on the basis that 7364 is accepted, and I will also propose changes to chapter 9 to reflect the discussion in this thread. I will try to do it before the end of the week. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 19:59 To: Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Ok looks like we need a new issue to docuement the inconsistency discovered below. Jeurgen, can you please open one taking the thread below as text? Now, that this is sorted out, it appears that we indeed had a precedence where we had to "copy down" structure (in this case we copied Kernel::Classifier::attribute down to InternalStructures::Classifier), although we did not "document" it properly, leading to the confusion. Now, in the new case of having to "copy down", I guess we need to document this more, by having proper subclauses that references the others by (see xxx for details). What I am not sure about is the level of copy vs. reference in the text. For example, part of what I have to copy in the metamodel is a derived association that has a derivation and constraints...etc. Do I copy those? All in all, I think since we are setting a precedence in this "copy down" documentation, we better do it carefully through a new issue resolution that we review. Steve, can you prepare such a resolution? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/21/2009 02:40 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Subject RE: resolution 7364 from ballot 8 (Components) Maged -- Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property [EVS] Actually, it subsets Kernel::Classifier:attribute. There is no Kernel::Classifier::property . so I will just assume you mean Kernel::Classifier::attribute in the following. 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. [EVS] Good point! (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. [EVS] OK, now I understand.and I agree with that the above proposed changes are necessary. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. [EVS] Yes, I think you are right here, too. But this really does need to be a new issue. This package merge stuff really makes my head hurt (and I thought figuring out the action semantics was bad enough!). -- Ed pic23689.gif From: Steve Cook To: Maged Elaasar CC: Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Date: Thu, 23 Jul 2009 16:41:36 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoLm7GSnQTw8nMxTp24HRqrrlxvcQAEBd7Q Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Right . to fix that we have to say that InternalStructures::StructuredClassifier specializes InternalStructures::Classifier AND Kernel::Classifier. Then these two generalizations ultimately get merged into one. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 23 July 2009 14:44 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, the only remaining issue would be InternalStructures::StructuredClassifier::ownedConnector subsetting Kernel::Classifier::feature Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/23/2009 08:00 AM To Maged Elaasar/Ottawa/IBM@IBMCA, Ed Seidewitz cc "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) I.m preparing this resolution (for which an issue number is still needed) and looking at the problems with InternalStructures::Classsifier. If we do as suggested, i.e. Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier, then it makes InternalStructures::StructuredClassifier::ownedAttribute legally subset InternalStructures::Classifier::attribute. So far so good. However, we then have the problem of InternalStructures::StructuredClassifier::ownedAttribute subsetting ownedMember, and similarly ownedConnector subsetting ownedMember. I believe this means that we have to also say that InternalStructures::Classifier should specialize Kernel::Namespace. Now, if you look at 9.7, you see that Collaboration::Classifier specializes RedefinableElement, Namespace and Type. I cannot see any reason why it should specialize all of these. All it actually needs is to specialize Element so it gets access to ownedElement. Hence I suggest that we have a single Generalizations clause in 9.3.2, showing that Classifier (InternalStuctures and Collaborations) specializes Kernel::Namespace, and change 9.7 so that Classifier only specializes Kernel::Namespace. Thoughts? -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 22 July 2009 10:16 To: Maged Elaasar; Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org; issues@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) First, I.m copying the thread to issues@omg.org because you.ve asked Juergen for a new issue number. I think the title of the issue should be .Need to copy down merged content to make constraints valid in receiving package.. Juergen, can we have a number urgently please? Yes, I will draft a resolution to it. I will propose changes on the basis that 7364 is accepted, and I will also propose changes to chapter 9 to reflect the discussion in this thread. I will try to do it before the end of the week. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 19:59 To: Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Ok looks like we need a new issue to docuement the inconsistency discovered below. Jeurgen, can you please open one taking the thread below as text? Now, that this is sorted out, it appears that we indeed had a precedence where we had to "copy down" structure (in this case we copied Kernel::Classifier::attribute down to InternalStructures::Classifier), although we did not "document" it properly, leading to the confusion. Now, in the new case of having to "copy down", I guess we need to document this more, by having proper subclauses that references the others by (see xxx for details). What I am not sure about is the level of copy vs. reference in the text. For example, part of what I have to copy in the metamodel is a derived association that has a derivation and constraints...etc. Do I copy those? All in all, I think since we are setting a precedence in this "copy down" documentation, we better do it carefully through a new issue resolution that we review. Steve, can you prepare such a resolution? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/21/2009 02:40 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Subject RE: resolution 7364 from ballot 8 (Components) Maged -- Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property [EVS] Actually, it subsets Kernel::Classifier:attribute. There is no Kernel::Classifier::property . so I will just assume you mean Kernel::Classifier::attribute in the following. 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. [EVS] Good point! (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. [EVS] OK, now I understand.and I agree with that the above proposed changes are necessary. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. [EVS] Yes, I think you are right here, too. But this really does need to be a new issue. This package merge stuff really makes my head hurt (and I thought figuring out the action semantics was bad enough!). -- Ed Subject: RE: resolution 7364 from ballot 8 (Components) To: Steve Cook Cc: Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 23 Jul 2009 11:53:00 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/23/2009 11:53:00 hmm, wouldn't this result in features with duplicate names in InternalStructures::StructuredClassifier, like "attribute"? since those come from inheritance (not package merge), they will not disappear in the merged StructuredClassifier. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/23/2009 11:41 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Right . to fix that we have to say that InternalStructures::StructuredClassifier specializes InternalStructures::Classifier AND Kernel::Classifier. Then these two generalizations ultimately get merged into one. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 23 July 2009 14:44 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, the only remaining issue would be InternalStructures::StructuredClassifier::ownedConnector subsetting Kernel::Classifier::feature Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/23/2009 08:00 AM To Maged Elaasar/Ottawa/IBM@IBMCA, Ed Seidewitz cc "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) I.m preparing this resolution (for which an issue number is still needed) and looking at the problems with InternalStructures::Classsifier. If we do as suggested, i.e. Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier, then it makes InternalStructures::StructuredClassifier::ownedAttribute legally subset InternalStructures::Classifier::attribute. So far so good. However, we then have the problem of InternalStructures::StructuredClassifier::ownedAttribute subsetting ownedMember, and similarly ownedConnector subsetting ownedMember. I believe this means that we have to also say that InternalStructures::Classifier should specialize Kernel::Namespace. Now, if you look at 9.7, you see that Collaboration::Classifier specializes RedefinableElement, Namespace and Type. I cannot see any reason why it should specialize all of these. All it actually needs is to specialize Element so it gets access to ownedElement. Hence I suggest that we have a single Generalizations clause in 9.3.2, showing that Classifier (InternalStuctures and Collaborations) specializes Kernel::Namespace, and change 9.7 so that Classifier only specializes Kernel::Namespace. Thoughts? -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 22 July 2009 10:16 To: Maged Elaasar; Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org; issues@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) First, I.m copying the thread to issues@omg.org because you.ve asked Juergen for a new issue number. I think the title of the issue should be .Need to copy down merged content to make constraints valid in receiving package.. Juergen, can we have a number urgently please? Yes, I will draft a resolution to it. I will propose changes on the basis that 7364 is accepted, and I will also propose changes to chapter 9 to reflect the discussion in this thread. I will try to do it before the end of the week. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 19:59 To: Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Ok looks like we need a new issue to docuement the inconsistency discovered below. Jeurgen, can you please open one taking the thread below as text? Now, that this is sorted out, it appears that we indeed had a precedence where we had to "copy down" structure (in this case we copied Kernel::Classifier::attribute down to InternalStructures::Classifier), although we did not "document" it properly, leading to the confusion. Now, in the new case of having to "copy down", I guess we need to document this more, by having proper subclauses that references the others by (see xxx for details). What I am not sure about is the level of copy vs. reference in the text. For example, part of what I have to copy in the metamodel is a derived association that has a derivation and constraints...etc. Do I copy those? All in all, I think since we are setting a precedence in this "copy down" documentation, we better do it carefully through a new issue resolution that we review. Steve, can you prepare such a resolution? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/21/2009 02:40 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Subject RE: resolution 7364 from ballot 8 (Components) Maged -- Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property [EVS] Actually, it subsets Kernel::Classifier:attribute. There is no Kernel::Classifier::property . so I will just assume you mean Kernel::Classifier::attribute in the following. 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. [EVS] Good point! (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. [EVS] OK, now I understand.and I agree with that the above proposed changes are necessary. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. [EVS] Yes, I think you are right here, too. But this really does need to be a new issue. This package merge stuff really makes my head hurt (and I thought figuring out the action semantics was bad enough!). -- Ed pic25967.gif From: Steve Cook To: Maged Elaasar CC: Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Date: Thu, 23 Jul 2009 17:04:19 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoLreQrr5feOTygTL2AA+CJAaX2LwAABi7A Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Hmm indeed. Then instead we have to introduce the /feature association to Kernel::Feature into InternalStructures::Classifier. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 23 July 2009 16:53 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) hmm, wouldn't this result in features with duplicate names in InternalStructures::StructuredClassifier, like "attribute"? since those come from inheritance (not package merge), they will not disappear in the merged StructuredClassifier. Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/23/2009 11:41 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) Right . to fix that we have to say that InternalStructures::StructuredClassifier specializes InternalStructures::Classifier AND Kernel::Classifier. Then these two generalizations ultimately get merged into one. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 23 July 2009 14:44 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, the only remaining issue would be InternalStructures::StructuredClassifier::ownedConnector subsetting Kernel::Classifier::feature Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/23/2009 08:00 AM To Maged Elaasar/Ottawa/IBM@IBMCA, Ed Seidewitz cc "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) I.m preparing this resolution (for which an issue number is still needed) and looking at the problems with InternalStructures::Classsifier. If we do as suggested, i.e. Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier, then it makes InternalStructures::StructuredClassifier::ownedAttribute legally subset InternalStructures::Classifier::attribute. So far so good. However, we then have the problem of InternalStructures::StructuredClassifier::ownedAttribute subsetting ownedMember, and similarly ownedConnector subsetting ownedMember. I believe this means that we have to also say that InternalStructures::Classifier should specialize Kernel::Namespace. Now, if you look at 9.7, you see that Collaboration::Classifier specializes RedefinableElement, Namespace and Type. I cannot see any reason why it should specialize all of these. All it actually needs is to specialize Element so it gets access to ownedElement. Hence I suggest that we have a single Generalizations clause in 9.3.2, showing that Classifier (InternalStuctures and Collaborations) specializes Kernel::Namespace, and change 9.7 so that Classifier only specializes Kernel::Namespace. Thoughts? -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 22 July 2009 10:16 To: Maged Elaasar; Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org; issues@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) First, I.m copying the thread to issues@omg.org because you.ve asked Juergen for a new issue number. I think the title of the issue should be .Need to copy down merged content to make constraints valid in receiving package.. Juergen, can we have a number urgently please? Yes, I will draft a resolution to it. I will propose changes on the basis that 7364 is accepted, and I will also propose changes to chapter 9 to reflect the discussion in this thread. I will try to do it before the end of the week. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 19:59 To: Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Ok looks like we need a new issue to docuement the inconsistency discovered below. Jeurgen, can you please open one taking the thread below as text? Now, that this is sorted out, it appears that we indeed had a precedence where we had to "copy down" structure (in this case we copied Kernel::Classifier::attribute down to InternalStructures::Classifier), although we did not "document" it properly, leading to the confusion. Now, in the new case of having to "copy down", I guess we need to document this more, by having proper subclauses that references the others by (see xxx for details). What I am not sure about is the level of copy vs. reference in the text. For example, part of what I have to copy in the metamodel is a derived association that has a derivation and constraints...etc. Do I copy those? All in all, I think since we are setting a precedence in this "copy down" documentation, we better do it carefully through a new issue resolution that we review. Steve, can you prepare such a resolution? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/21/2009 02:40 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Subject RE: resolution 7364 from ballot 8 (Components) Maged -- Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property [EVS] Actually, it subsets Kernel::Classifier:attribute. There is no Kernel::Classifier::property . so I will just assume you mean Kernel::Classifier::attribute in the following. 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. [EVS] Good point! (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. [EVS] OK, now I understand.and I agree with that the above proposed changes are necessary. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. [EVS] Yes, I think you are right here, too. But this really does need to be a new issue. This package merge stuff really makes my head hurt (and I thought figuring out the action semantics was bad enough!). -- Ed From: Steve Cook To: Juergen Boldt Date: Fri, 24 Jul 2009 08:54:04 +0100 Subject: FW: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoKNdwp1tA8pgYvQEOtE7SWU3EiCAAdjLowAGHpDeA= Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Juergen, we urgently need an issue number for .Need to copy down merged content to make constraints parse in receiving package. with summary consisting of the email below. We want to shoehorn it into the current ballot. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 22 July 2009 10:16 To: Maged Elaasar; Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org; issues@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) First, I.m copying the thread to issues@omg.org because you.ve asked Juergen for a new issue number. I think the title of the issue should be .Need to copy down merged content to make constraints valid in receiving package.. Juergen, can we have a number urgently please? Yes, I will draft a resolution to it. I will propose changes on the basis that 7364 is accepted, and I will also propose changes to chapter 9 to reflect the discussion in this thread. I will try to do it before the end of the week. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 19:59 To: Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Ok looks like we need a new issue to docuement the inconsistency discovered below. Jeurgen, can you please open one taking the thread below as text? Now, that this is sorted out, it appears that we indeed had a precedence where we had to "copy down" structure (in this case we copied Kernel::Classifier::attribute down to InternalStructures::Classifier), although we did not "document" it properly, leading to the confusion. Now, in the new case of having to "copy down", I guess we need to document this more, by having proper subclauses that references the others by (see xxx for details). What I am not sure about is the level of copy vs. reference in the text. For example, part of what I have to copy in the metamodel is a derived association that has a derivation and constraints...etc. Do I copy those? All in all, I think since we are setting a precedence in this "copy down" documentation, we better do it carefully through a new issue resolution that we review. Steve, can you prepare such a resolution? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/21/2009 02:40 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Subject RE: resolution 7364 from ballot 8 (Components) Maged -- Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property [EVS] Actually, it subsets Kernel::Classifier:attribute. There is no Kernel::Classifier::property . so I will just assume you mean Kernel::Classifier::attribute in the following. 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. [EVS] Good point! (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. [EVS] OK, now I understand.and I agree with that the above proposed changes are necessary. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. [EVS] Yes, I think you are right here, too. But this really does need to be a new issue. This package merge stuff really makes my head hurt (and I thought figuring out the action semantics was bad enough!). -- Ed From: Steve Cook To: Maged Elaasar CC: Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Date: Fri, 24 Jul 2009 19:12:40 +0100 Subject: RE: resolution 7364 from ballot 8 (Components) Thread-Topic: resolution 7364 from ballot 8 (Components) Thread-Index: AcoLm7GSnQTw8nMxTp24HRqrrlxvcQA7nCOA Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US I.ve prepared a draft resolution but we don.t have a bug number yet. The resolution is attached. I am finishing work for this week now. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 23 July 2009 14:44 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, the only remaining issue would be InternalStructures::StructuredClassifier::ownedConnector subsetting Kernel::Classifier::feature Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/23/2009 08:00 AM To Maged Elaasar/Ottawa/IBM@IBMCA, Ed Seidewitz cc "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) I.m preparing this resolution (for which an issue number is still needed) and looking at the problems with InternalStructures::Classsifier. If we do as suggested, i.e. Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier, then it makes InternalStructures::StructuredClassifier::ownedAttribute legally subset InternalStructures::Classifier::attribute. So far so good. However, we then have the problem of InternalStructures::StructuredClassifier::ownedAttribute subsetting ownedMember, and similarly ownedConnector subsetting ownedMember. I believe this means that we have to also say that InternalStructures::Classifier should specialize Kernel::Namespace. Now, if you look at 9.7, you see that Collaboration::Classifier specializes RedefinableElement, Namespace and Type. I cannot see any reason why it should specialize all of these. All it actually needs is to specialize Element so it gets access to ownedElement. Hence I suggest that we have a single Generalizations clause in 9.3.2, showing that Classifier (InternalStuctures and Collaborations) specializes Kernel::Namespace, and change 9.7 so that Classifier only specializes Kernel::Namespace. Thoughts? -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 22 July 2009 10:16 To: Maged Elaasar; Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org; issues@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) First, I.m copying the thread to issues@omg.org because you.ve asked Juergen for a new issue number. I think the title of the issue should be .Need to copy down merged content to make constraints valid in receiving package.. Juergen, can we have a number urgently please? Yes, I will draft a resolution to it. I will propose changes on the basis that 7364 is accepted, and I will also propose changes to chapter 9 to reflect the discussion in this thread. I will try to do it before the end of the week. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 19:59 To: Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Ok looks like we need a new issue to docuement the inconsistency discovered below. Jeurgen, can you please open one taking the thread below as text? Now, that this is sorted out, it appears that we indeed had a precedence where we had to "copy down" structure (in this case we copied Kernel::Classifier::attribute down to InternalStructures::Classifier), although we did not "document" it properly, leading to the confusion. Now, in the new case of having to "copy down", I guess we need to document this more, by having proper subclauses that references the others by (see xxx for details). What I am not sure about is the level of copy vs. reference in the text. For example, part of what I have to copy in the metamodel is a derived association that has a derivation and constraints...etc. Do I copy those? All in all, I think since we are setting a precedence in this "copy down" documentation, we better do it carefully through a new issue resolution that we review. Steve, can you prepare such a resolution? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/21/2009 02:40 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Subject RE: resolution 7364 from ballot 8 (Components) Maged -- Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property [EVS] Actually, it subsets Kernel::Classifier:attribute. There is no Kernel::Classifier::property . so I will just assume you mean Kernel::Classifier::attribute in the following. 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. [EVS] Good point! (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. [EVS] OK, now I understand.and I agree with that the above proposed changes are necessary. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. [EVS] Yes, I think you are right here, too. But this really does need to be a new issue. This package merge stuff really makes my head hurt (and I thought figuring out the action semantics was bad enough!). -- Ed UML 2.3 Resolutiion merge.doc DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=JbnOQyQ0mB2FoKAh53qiDqoZYySkpvFGSjNHta+GjJ8=; b=BSL0EDP75uUoKsXBdrk01vFsKcPeGq/kPzNzy0HEcbUbOUIvzcpPnPNfekMpm/ySfY 5AwhouC2M5cR2hfzlCXTo2Gl4tkAb56D11jIPN/MAUUPZEQDsSBV4xX3aD0W1six5Uyv wbNjayfu9dOqBlKh0qlPfiNIYvOrCpX3jUg3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FbcNSoYjCfBy9wrB4GhZNMx3QHbzTSGAjpHcYoFMXEIW21tqdORnMudQJUtV+37fyI Sq+GMcgfivgks4rtPMUkSwedKWju/RbEKe+i6V+iKtcMRnPnt2leUK2Bs+netlSEgcyV dZtTS0yvGV8RPEbbTlXKuT0avnzBf4AnW36og= Date: Fri, 24 Jul 2009 15:25:35 -0400 Subject: Re: resolution 7364 from ballot 8 (Components) From: Bran Selic To: Steve Cook Cc: Maged Elaasar , Ed Seidewitz , "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Steve, have you asked Juergen for a number yet? He is usually very responsive and can get you a bug number in minutes flat. Bran On Fri, Jul 24, 2009 at 2:12 PM, Steve Cook wrote: I.ve prepared a draft resolution but we don.t have a bug number yet. The resolution is attached. I am finishing work for this week now. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 23 July 2009 14:44 To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Steve, the only remaining issue would be InternalStructures::StructuredClassifier::ownedConnector subsetting Kernel::Classifier::feature Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook Steve Cook 07/23/2009 08:00 AM To Maged Elaasar/Ottawa/IBM@IBMCA, Ed Seidewitz cc "Rouquette, Nicolas F (316A)" , "uml2-rtf@omg.org" Subject RE: resolution 7364 from ballot 8 (Components) I.m preparing this resolution (for which an issue number is still needed) and looking at the problems with InternalStructures::Classsifier. If we do as suggested, i.e. Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier, then it makes InternalStructures::StructuredClassifier::ownedAttribute legally subset InternalStructures::Classifier::attribute. So far so good. However, we then have the problem of InternalStructures::StructuredClassifier::ownedAttribute subsetting ownedMember, and similarly ownedConnector subsetting ownedMember. I believe this means that we have to also say that InternalStructures::Classifier should specialize Kernel::Namespace. Now, if you look at 9.7, you see that Collaboration::Classifier specializes RedefinableElement, Namespace and Type. I cannot see any reason why it should specialize all of these. All it actually needs is to specialize Element so it gets access to ownedElement. Hence I suggest that we have a single Generalizations clause in 9.3.2, showing that Classifier (InternalStuctures and Collaborations) specializes Kernel::Namespace, and change 9.7 so that Classifier only specializes Kernel::Namespace. Thoughts? -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 22 July 2009 10:16 To: Maged Elaasar; Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org; issues@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) First, I.m copying the thread to issues@omg.org because you.ve asked Juergen for a new issue number. I think the title of the issue should be .Need to copy down merged content to make constraints valid in receiving package.. Juergen, can we have a number urgently please? Yes, I will draft a resolution to it. I will propose changes on the basis that 7364 is accepted, and I will also propose changes to chapter 9 to reflect the discussion in this thread. I will try to do it before the end of the week. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 21 July 2009 19:59 To: Ed Seidewitz Cc: Rouquette, Nicolas F (316A); uml2-rtf@omg.org Subject: RE: resolution 7364 from ballot 8 (Components) Ok looks like we need a new issue to docuement the inconsistency discovered below. Jeurgen, can you please open one taking the thread below as text? Now, that this is sorted out, it appears that we indeed had a precedence where we had to "copy down" structure (in this case we copied Kernel::Classifier::attribute down to InternalStructures::Classifier), although we did not "document" it properly, leading to the confusion. Now, in the new case of having to "copy down", I guess we need to document this more, by having proper subclauses that references the others by (see xxx for details). What I am not sure about is the level of copy vs. reference in the text. For example, part of what I have to copy in the metamodel is a derived association that has a derivation and constraints...etc. Do I copy those? All in all, I think since we are setting a precedence in this "copy down" documentation, we better do it carefully through a new issue resolution that we review. Steve, can you prepare such a resolution? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Ed Seidewitz" "Ed Seidewitz" 07/21/2009 02:40 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Subject RE: resolution 7364 from ballot 8 (Components) Maged -- Currently in the metamodel: 1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::property [EVS] Actually, it subsets Kernel::Classifier:attribute. There is no Kernel::Classifier::property . so I will just assume you mean Kernel::Classifier::attribute in the following. 2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else. A question: is the subsetting in 1 valid? The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::property is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel. [EVS] Good point! (((However, If the answer to the question was "Yes", then as Bran and Ed said, we would not need InternalStructures::Classifier merge increment.))) So to make things consistent, as Nic said, we should: - Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier - Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute. [EVS] OK, now I understand.and I agree with that the above proposed changes are necessary. in addition: - don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures? - Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration". - So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. [EVS] Yes, I think you are right here, too. But this really does need to be a new issue. This package merge stuff really makes my head hurt (and I thought figuring out the action semantics was bad enough!). -- Ed Content-Type: image/png; name="image002.png" Content-ID: X-Attachment-Id: 0.0.2 Content-Type: image/png; name="image003.png" Content-ID: X-Attachment-Id: 0.0.3 Content-Type: image/gif; name="image001.gif" Content-ID: X-Attachment-Id: 0.0.1