UML 2.2 RTF Avatar
  1. OMG Issue

UML22 — section on connectors in the component chapter

  • Key: UML22-1376
  • Legacy Issue Number: 7364
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • 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.

  • Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    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).

  • Updated: Sun, 8 Mar 2015 15:08 GMT