Issue 8160: Section: 11.3.16 (uml2-rtf) Source: (, ) Nature: Clarification Severity: Minor Summary: Constraint 1 says that the classifier cannot be abstract but fig. 146 shows the Classifier name in italics. Delete header Examples as there are none Resolution: Revised Text: Actions taken: January 27, 2005: received issue August 23, 2006: closed issue Discussion: The classifier referred to in the constraint is from the user model. The one in Figure 146 is from the UML metamodel. Disposition: Closed, no change End of Annotations:===== m: webmaster@omg.org Date: 27 Jan 2005 16:24:46 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Jane Messenger Company: U. S. Geological Survey mailFrom: jmessenger@usgs.gov Notification: Yes Specification: Superstructure Section: 11.3.16 FormalNumber: ptc/04-10-02 Version: 2.0 Draft Adopted RevisionDate: 10/08/2004 Page: 270 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description Constraint 1 says that the classifier cannot be abstract but fig. 146 shows the Classifier name in italics. Delete header Examples as there are none. 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