Issue 7247: Connector - "provided Port" and "required Port" not defined Constraint 1 (uml2-rtf) Source: (, ) Nature: Clarification Severity: Significant Summary: Connector - "provided Port" and "required Port" not defined Constraint 1, "[1] A delegation connector must only be defined between used Interfaces or Ports of the same kind, e.g. between two provided Ports or between two required Ports." uses the concepts "provided Port" and "required Port". Neither of them is defined in the spec. Furthermore, a Connector is not expected to be defined between Interfaces, but an Association is. A Connector is defined between ConnectableElements whose specializations are Property, Port, Parameter, and Variable, but not Interface. I suggest to replace Constraint [1] with "[1] A delegation connector must only be defined between a ConnectableElement (i.e. a Port) of the component and a ConnectableElement (i.e. a Property or a Port) of one of its internal parts." Resolution: The proposed resolution is still incorrect because a connector in general is n-ary not binary. Also the need for such a constraint is altered because of the resolution of 7364 which makes Connector::kind derived. Instead we need a constraint that ensures that a delegation connector only delegates from one port: it would make no sense to have an n-ary connector that delegated from more than one port. Furthermore the entire Semantics section for Connector in this chapter needs rewriting because of this issue. Revised Text: Replace 8.3.3 constraint [1] which currently says: [1] A delegation connector must only be defined between used Interfaces or Ports of the same kind (e.g., between two provided Ports or between two required Ports). By [1] Each feature of each of the required interfaces of each Port or Part at the end of a connector must have at least one compatible feature among the features of the provided interfaces of Ports or Parts at the other ends, where the required set of (interface) features of a delegating port from the context of the delegating connector is the set of features that exist in the port's provided interfaces, and the provided set of (interface) features of a delegating port from the context of the delegating connector is the set of features that exist in the port's required interfaces. Replace the whole of the section 8.3.3 Semantics by the following: "A delegation connector is a declaration that behavior that is available on a component instance is not actually realized by that component itself, but by one or more instances that have "compatible" capabilities. These situations are modeled through a delegation connector from a Port to compatible Ports or Parts. Delegation connectors can be used to model the hierarchical decomposition of behavior, where services provided by a component may ultimately be realized by one that is nested multiple levels deep within it. The word delegation suggests that concrete message and signal flow will occur between the connected ports, possibly over multiple levels. It should be noted that such signal flow is not always realized in all system environments or implementations (i.e., it may be design time only). A port may delegate to a set of ports on subordinate components. In that case, these subordinate ports must collectively offer the delegated functionality of the delegating port. At execution time, signals will be delivered to the appropriate port. In cases where multiple target ports support the handling of the same signal, the signal will be delivered to all these subordinate ports. The execution time semantics for an assembly connector are that signals travel along an instance of a connector. Multiple connectors directed to and from different parts, or n-ary connectors where n> 2, indicates that the instance that will originate or handle the signal will be determined at execution time. The interface compatibility between ports that are connected enables an existing component in a system to be replaced by one that (minimally) offers the same set of services. Also, in contexts where components are used to extend a system by offering existing services, but also adding new functionality, connectors can be used to link in the new component definition." Note: I have not attempted the OCL for the constraint in this resolution. That can be a subsequent issue. Actions taken: April 15, 2004: received issue April 26, 2010: closed issue April 26, 2010: closed issue Discussion: Resolution deferred for the next RTF End of Annotations:===== From: webmaster@omg.org Date: 15 Apr 2004 11:02:11 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Karl Guggisberg Company: na mailFrom: karl.guggisberg@guggis.ch Notification: Yes Specification: Unified Modeling Language: Superstructure Section: 8.3.2 FormalNumber: ptc/03-08-02 Version: 2.0 RevisionDate: na Page: 143 Nature: Clarification Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Description Issue 7247: Connector - 'provided Port' and 'required Port' not defined Constraint 1 Issue summary Connector - 'provided Port' and 'required Port' not defined Constraint 1, '[1] A delegation connector must only be defined between used Interfaces or Ports of the same kind, e.g. between two provided Ports or between two required Ports.' uses the concepts 'provided Port' and 'required Port'. Neither of them is defined in the spec. Furthermore, a Connector is not expected to be defined between Interfaces, but an Association is. A Connector is defined between Connectable Elements? whose specializations are Property, Port, Parameter, and Variable, but not Interface. I suggest to replace Constraint [1] with '[1] A delegation connector must only be defined between a Connectable Element? (i.e. a Port) of the component and a Connectable Element? (i.e. a Property or a Port) of one of its internal parts.' Discussion Revised Test Resolution Subject: Issue 7247 and 7248 To: Steve Cook Cc: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Adam Neal Date: Tue, 5 May 2009 11:48:31 -0400 X-MIMETrack: Serialize by Router on D25ML02/25/M/IBM(Release 8.0.1|February 07, 2008) at 05/05/2009 11:48:37 (Resending with modified Subject so the issue under discussion is more easily tracked) ----------------------------- Hi Steve, I have some issues with the proposed changes under section 8.3.3 (Connector). I don't agree with the proposed constraint [1] from 7247: "[1] A connector may have no more than one end that connects to a Port and does not also connect to a Part. end->select( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty())->size() <= 1" Consider the following diagram: r1 and r2 are non-behavior ports on the encapsulation shell of class: Capsule2 b1 and b2 are non-service behavior ports that are internal (private/protected) to Capsule2. A delegation connector between r1 and r2 is perfectly valid. What is the reasoning against allowing one to forward incoming requests directly as in the above diagram? The assembly connector between b1 and b2 allows the classifier to send itself internal messages to be handled by its owned classifier behavior. This is also a common for RT. My problem with [1] is that it disallows both these cases. I also feel that constraints [3] and [4] which are also proposed to be removed, provide justifiable guidance to users. What does it mean if we don't have these constraints? That ports which provide incompatible interfaces can be connected? This seems like something fundamental that should continue to be disallowed. I'm not sure how to handle the case where one is not using ports as we I don't believe we can connect to the lollipops/sockets (which is perhaps one reason to force the use of ports), but for connected ports, at least, it should be clear. May I suggest: [2] The required interfaces of any port at an end of a connector must be realized by the union of the provided interfaces of the ports at the other ends. Thanks, Adam Steve Cook Steve Cook 04/28/2009 06:20 AM To "uml2-rtf@omg.org" cc Subject Proposed component resolutions in Ballot 6 Drafts I have dropped a document with a large number of Component resolutions into Ballot 6 Drafts. The document is called UML 2.3 Resolution Components - 090427 Cook.doc and addresses the following issues: 6433, 7247, 7248, 7249, 7250, 7251, 7364, 8106, 8168, 8705, 8900, 9413, 9464, 9578, 9807, 10526, 10651, 12241, 12985, 13146. Many of these issues are very interdependent and concern mistaken or problematic notions like connectors wiring to interfaces, provided/required ports, and ball and socket notation. In order to help me do this and to help people to review it I have created a .convenience document. with all the changes marked and cross-referenced to issues. This is also in Ballot 6 Drafts and called 8Components.proposed.doc. Your comments would be much appreciated. Thanks -- Steve pic20913.gif Subject: Issue 7247 and 7248 To: Steve Cook Cc: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Adam Neal Date: Tue, 5 May 2009 12:30:59 -0400 X-MIMETrack: Serialize by Router on D25ML02/25/M/IBM(Release 8.0.1|February 07, 2008) at 05/05/2009 12:31:11 (Resending with updated subject so its easier to identify in mailing list) ----------------------------------- Hi Steve, I have some issues with the proposed changes under section 8.3.3 (Connector). I don't agree with the proposed constraint [1] from 7247: "[1] A connector may have no more than one end that connects to a Port and does not also connect to a Part. end->select( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty())->size() <= 1" Consider the following diagram: r1 and r2 are non-behavior ports on the encapsulation shell of class: Capsule2 b1 and b2 are non-service behavior ports that are internal (private/protected) to Capsule2. A delegation connector between r1 and r2 is perfectly valid. What is the reasoning against allowing one to forward incoming requests directly as in the above diagram? The assembly connector between b1 and b2 allows the classifier to send itself internal messages to be handled by its owned classifier behavior. This is also a common for RT. My problem with [1] is that it disallows both these cases. I also feel that constraints [3] and [4] which are also proposed to be removed, provide justifiable guidance to users. What does it mean if we don't have these constraints? That ports which provide incompatible interfaces can be connected? This seems like something fundamental that should continue to be disallowed. I'm not sure how to handle the case where one is not using ports as we I don't believe we can connect to the lollipops/sockets (which is perhaps one reason to force the use of ports), but for connected ports, at least, it should be clear. May I suggest: [2] The required interfaces of any port at an end of a connector must be realized by the union of the provided interfaces of the ports at the other ends. Thanks, Adam Steve Cook Steve Cook 04/28/2009 06:20 AM To "uml2-rtf@omg.org" cc Subject Proposed component resolutions in Ballot 6 Drafts I have dropped a document with a large number of Component resolutions into Ballot 6 Drafts. The document is called UML 2.3 Resolution Components - 090427 Cook.doc and addresses the following issues: 6433, 7247, 7248, 7249, 7250, 7251, 7364, 8106, 8168, 8705, 8900, 9413, 9464, 9578, 9807, 10526, 10651, 12241, 12985, 13146. Many of these issues are very interdependent and concern mistaken or problematic notions like connectors wiring to interfaces, provided/required ports, and ball and socket notation. In order to help me do this and to help people to review it I have created a .convenience document. with all the changes marked and cross-referenced to issues. This is also in Ballot 6 Drafts and called 8Components.proposed.doc. Your comments would be much appreciated. Thanks -- Steve pic01759.gif From: Steve Cook To: Adam Neal CC: "uml2-rtf@omg.org" Date: Wed, 6 May 2009 10:06:57 +0100 Subject: RE: Issue 7247 and 7248 Thread-Topic: Issue 7247 and 7248 Thread-Index: AcnNmRxA9nG0dNn/RnaWBlyasFtduQAjsmGQ Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Adam I am happy to drop constraint [1] on the basis of this feedback and will do so. With regard to your comment about dropping the other constraints I refer you to Bran.s issue 10526: .The constraints defined for Connectors in the components chapter should be removed: they refer to "provided" and "required" ports (categories no longer supported in UML) but also force very stringent connection rules that get in the way of informal sketching type usage, since they require the explicit declaration of interfaces when doing structure modeling. These types of constraints should only be enforced through a profile.. Also the one you have proposed .[2] The required interfaces of any port at an end of a connector must be realized by the union of the provided interfaces of the ports at the other ends.. seems problematic to me. Do you mean .the union of the required interfaces of any port ... must be realized by the union of the provided interfaces ....? Or do you mean each of the required interfaces must be realized by some subset of the union of the provided interfaces? Or something else? In any case I don.t know what the union of a set of interfaces is. Plus I refer to the following statement in chapter 9: .What makes connectable elements compatible is a semantic variation point.. If it is a semantic variation point in chapter 9, why is it not a semantic variation point in chapter8? Given these three points it seems to me that the weight of the argument is strongly in favour of no additional constraints. -- Steve From: Adam Neal [mailto:Adam_Neal@ca.ibm.com] Sent: 05 May 2009 16:49 To: Steve Cook Cc: uml2-rtf@omg.org Subject: Issue 7247 and 7248 (Resending with modified Subject so the issue under discussion is more easily tracked) ----------------------------- Hi Steve, I have some issues with the proposed changes under section 8.3.3 (Connector). I don't agree with the proposed constraint [1] from 7247: "[1] A connector may have no more than one end that connects to a Port and does not also connect to a Part. end->select( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty())->size() <= 1" Consider the following diagram: r1 and r2 are non-behavior ports on the encapsulation shell of class: Capsule2 b1 and b2 are non-service behavior ports that are internal (private/protected) to Capsule2. A delegation connector between r1 and r2 is perfectly valid. What is the reasoning against allowing one to forward incoming requests directly as in the above diagram? The assembly connector between b1 and b2 allows the classifier to send itself internal messages to be handled by its owned classifier behavior. This is also a common for RT. My problem with [1] is that it disallows both these cases. I also feel that constraints [3] and [4] which are also proposed to be removed, provide justifiable guidance to users. What does it mean if we don't have these constraints? That ports which provide incompatible interfaces can be connected? This seems like something fundamental that should continue to be disallowed. I'm not sure how to handle the case where one is not using ports as we I don't believe we can connect to the lollipops/sockets (which is perhaps one reason to force the use of ports), but for connected ports, at least, it should be clear. May I suggest: [2] The required interfaces of any port at an end of a connector must be realized by the union of the provided interfaces of the ports at the other ends. Thanks, Adam Steve Cook Steve Cook 04/28/2009 06:20 AM To "uml2-rtf@omg.org" cc Subject Proposed component resolutions in Ballot 6 Drafts I have dropped a document with a large number of Component resolutions into Ballot 6 Drafts. The document is called UML 2.3 Resolution Components - 090427 Cook.doc and addresses the following issues: 6433, 7247, 7248, 7249, 7250, 7251, 7364, 8106, 8168, 8705, 8900, 9413, 9464, 9578, 9807, 10526, 10651, 12241, 12985, 13146. Many of these issues are very interdependent and concern mistaken or problematic notions like connectors wiring to interfaces, provided/required ports, and ball and socket notation. In order to help me do this and to help people to review it I have created a .convenience document. with all the changes marked and cross-referenced to issues. This is also in Ballot 6 Drafts and called 8Components.proposed.doc. Your comments would be much appreciated. Thanks -- Steve Subject: RE: Issue 7247 and 7248 To: Steve Cook Cc: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Adam Neal Date: Wed, 6 May 2009 20:31:14 -0400 X-MIMETrack: Serialize by Router on D25ML02/25/M/IBM(Release 8.0.1|February 07, 2008) at 05/06/2009 20:33:29 Hi, Bran, in regards your issue 10526, I agree that we shouldn't have constraints which disallow informal sketching. But were you suggesting that when we have a connector between ports, which do have provided/required interfaces, that we shouldn't ensure that those connections are well-formed? Perhaps I'm unclear about the 'informal sketching' issue, but I would expect this constraint (below) to exist mainly to help users validate models when they want to test its well-formedness. Steve, your provided resolution for the semantics of 8.3.3 includes the following (issue 7247): "A port may delegate to a set of ports on subordinate components. In that case, these subordinate ports must collectively offer the delegated functionality of the delegating port. " "The interface compatibility between ports that are connected enables an existing component in a system to be replaced by one that (minimally) offers the same set of services" I am suggesting that this constraining text continue to exist as a real constraint (which is what I believe [3] and [4] were trying to do). I agree that talking about 'union of interfaces' is perhaps ambiguous, rather we should talk in terms of the set of features of an interface. As you mentioned, determining compatibility of connected elements is a semantic variation point. Though I'd like to suggest that we try to define compatibility for connected ports, and leave the semantic variation point to describe connectors involving other elements. Your provided text already implies this compatibility of ports; and I quote "The interface compatibility between ports that are connected". Just to help visualize it, let's consider the simple case of a binary connector: where 'p*' is the set of features in the provided interfaces of the port, and 'r*' is the set of features in the required interfaces of a port. Note, normally when we talk about provided/required interfaces, we are discussing in terms of the 'external' side of a port which exposes these interfaces. But when we discuss the 'delegate' connector, it is important to note that it is actually connecting to the 'internal' side of the delegating port, where conceptually the provided/required interfaces are 'conjugated'; which is necessary so that the port can actually receive these delegate messages, and pass them on. Also, it should be noted that connecting to the inside of a port implies that its behavior=false; behavior=true would imply that the signal is essentially terminated and not delegated. Though, when we connect to the external side of a port, whether it has behavior or not is irrelevant. When we discuss an assembly connector, if a port with required set of (interface) features, 'r1', has a feature that is not compatible with any feature defined in p2, then this connection should be ill-formed. In terms of the delegate connector we must constrain it as you've said: "subordinate ports must collectively offer the delegated functionality of the delegating port.". i.e. r3 can require more than r4, but at minimum must require what r4 requires. If r4 requires a feature that r3 does not, then this too should be considered ill-formed. Similarly, p4 can provide more than p3, but at minimum it must provide what p3 provides. I believe this can all be handled by one constraint. Though special consideration must be given to delegate connectors connecting to the 'inside' of a delegating port such that the correct set of required/provided features are considered. So, I will suggest we add: The required set of (interface) features of a delegating port from the context of the delegating connector are derived from the set of features that exist in the port's provided interfaces. The provided set of (interface) features of a delegating port from the context of the delegating connector are derived from the set of features that exist in the port's required interfaces. And: [1] Each feature of each of the required interfaces of each port at an end of a connector must have at least one COMPATIBLE feature among the features of the provided interfaces of ports at the other ends. Note: I use 'COMPATIBLE' for lack of a better word, if there is one, and welcome any suggestions. Regards, -Adam P.S. Sorry to write this and run, but I will be unavailable as of tomorrow, and will not be able to respond until I return on May 18th Steve Cook Steve Cook 05/06/2009 05:06 AM To Adam Neal/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: Issue 7247 and 7248 Adam I am happy to drop constraint [1] on the basis of this feedback and will do so. With regard to your comment about dropping the other constraints I refer you to Bran.s issue 10526: .The constraints defined for Connectors in the components chapter should be removed: they refer to "provided" and "required" ports (categories no longer supported in UML) but also force very stringent connection rules that get in the way of informal sketching type usage, since they require the explicit declaration of interfaces when doing structure modeling. These types of constraints should only be enforced through a profile.. Also the one you have proposed .[2] The required interfaces of any port at an end of a connector must be realized by the union of the provided interfaces of the ports at the other ends.. seems problematic to me. Do you mean .the union of the required interfaces of any port ... must be realized by the union of the provided interfaces ....? Or do you mean each of the required interfaces must be realized by some subset of the union of the provided interfaces? Or something else? In any case I don.t know what the union of a set of interfaces is. Plus I refer to the following statement in chapter 9: .What makes connectable elements compatible is a semantic variation point.. If it is a semantic variation point in chapter 9, why is it not a semantic variation point in chapter8? Given these three points it seems to me that the weight of the argument is strongly in favour of no additional constraints. -- Steve From: Adam Neal [mailto:Adam_Neal@ca.ibm.com] Sent: 05 May 2009 16:49 To: Steve Cook Cc: uml2-rtf@omg.org Subject: Issue 7247 and 7248 (Resending with modified Subject so the issue under discussion is more easily tracked) ----------------------------- Hi Steve, I have some issues with the proposed changes under section 8.3.3 (Connector). I don't agree with the proposed constraint [1] from 7247: "[1] A connector may have no more than one end that connects to a Port and does not also connect to a Part. end->select( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty())->size() <= 1" Consider the following diagram: r1 and r2 are non-behavior ports on the encapsulation shell of class: Capsule2 b1 and b2 are non-service behavior ports that are internal (private/protected) to Capsule2. A delegation connector between r1 and r2 is perfectly valid. What is the reasoning against allowing one to forward incoming requests directly as in the above diagram? The assembly connector between b1 and b2 allows the classifier to send itself internal messages to be handled by its owned classifier behavior. This is also a common for RT. My problem with [1] is that it disallows both these cases. I also feel that constraints [3] and [4] which are also proposed to be removed, provide justifiable guidance to users. What does it mean if we don't have these constraints? That ports which provide incompatible interfaces can be connected? This seems like something fundamental that should continue to be disallowed. I'm not sure how to handle the case where one is not using ports as we I don't believe we can connect to the lollipops/sockets (which is perhaps one reason to force the use of ports), but for connected ports, at least, it should be clear. May I suggest: [2] The required interfaces of any port at an end of a connector must be realized by the union of the provided interfaces of the ports at the other ends. Thanks, Adam Steve Cook Steve Cook 04/28/2009 06:20 AM To "uml2-rtf@omg.org" cc Subject Proposed component resolutions in Ballot 6 Drafts I have dropped a document with a large number of Component resolutions into Ballot 6 Drafts. The document is called UML 2.3 Resolution Components - 090427 Cook.doc and addresses the following issues: 6433, 7247, 7248, 7249, 7250, 7251, 7364, 8106, 8168, 8705, 8900, 9413, 9464, 9578, 9807, 10526, 10651, 12241, 12985, 13146. Many of these issues are very interdependent and concern mistaken or problematic notions like connectors wiring to interfaces, provided/required ports, and ball and socket notation. In order to help me do this and to help people to review it I have created a .convenience document. with all the changes marked and cross-referenced to issues. This is also in Ballot 6 Drafts and called 8Components.proposed.doc. Your comments would be much appreciated. Thanks -- Steve 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=CV/ssDK4HwxEBd7MuKub7j5gC/8tgcZV6NXHjLYRWjg=; b=hIj3uLUxLmrovvCiTZt+u9aEXWtIYs5Hvl3kMrvhdrjqXiqmpCBH85DqPoRoCpbWQf rVyBgHkX5hsKOsNtrk2KZoSIARyHlfAXNsGjIkdoaWrxV8jThlW9WmyUVAFzIS36bHqC xe6zQLg+FHp4xZqCr+H/0UJ2bDjHUiV+vgWik= 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=Yn0eyiK+eWRAlf5ScfYOZ60kb/h5+qCLFbCwMOTBUyHAd3Jf4NXkeVqiYvNVot//Bu Z0F88yQKkBaUR/A8rx8y2E61sePh3cQ5yXfq0fGbLHq2I2zPeHeJMj6RPWEsOGvsG83Q qUvBwAlz8e2J73br03ZzONz0yOl0c0VcHsm/A= Date: Fri, 8 May 2009 07:14:04 -0400 Subject: Re: Proposed component resolutions in Ballot 6 Drafts From: Bran Selic To: Steve Cook Cc: "uml2-rtf@omg.org" Hi Steve, I've reviewed the solutions you proposed and have concerns with two of them as described below. I apologize for not getting these in earlier, but I was involved in a rather disrupted mode in the past week. ========================================== Issue 6433 I have some concerns about this resolution proposal. First, from the text, it is not clear if these dependencies between components define wiring or merely constrain it in some way. In other words, does a dependency necessarily mean that wiring exists or simply implies the potential that wiring may exist.along the lines of associations with zero lower multiplicity ends. If it simply means that wiring may exist, some users will be confused about when to use these dependencies and when to use associations. This needs to be clarified better. Second.and this is really a problem with the original text and not the proposed resolution.it is unclear how such additional information is to be added, given that Dependencies have no special provisions for including such information. (As an aside, there is a conflict with the standard MARTE profile, which uses completely different mechanisms for supplying such data. This too will likely cause confusion.) Issue 7247 The statement in the proposed resolution: .A delegation connector is a declaration that behavior that is available on a component instance is not actually realized by that component itself, but by one or more instances that have .compatible. capabilities.. is problematic since it disallows the case where the delegation is from a port to another port. This seemingly strange configuration is actually more common in practice than might first appear. In some cases, it is used to realize a simple .pass-through. component, in which what comes into the component is simply relayed onwards through another port (this is useful to .null. out elements in a refinement of a generic structure). This is roughly equivalent to the concept of a .null. element in math. In yet other cases, the delegation may actually go to an internal behaviour port. Both of these patterns are used by UML-RT modelers (some make quite extensive use of them, in fact) and the impact of removing these capabilities would be substantial. ========================================== Regards...Bran On Tue, Apr 28, 2009 at 6:20 AM, Steve Cook wrote: I have dropped a document with a large number of Component resolutions into Ballot 6 Drafts.. The document is called UML 2.3 Resolution Components - 090427 Cook.doc and addresses the following issues: ny of these issues are very interdependent and concern mistaken or problematic notions like connectors wiring to interfaces, provided/required ports, and ball and socket notation.. In order to help me do this and to help people to review it I have created a .convenience document. with all the changes marked and cross-referenced to issues.. This is also in Ballot 6 Drafts and called 8Components.proposed.doc. . Your comments would be much appreciated. . Thanks .-- Steve 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=AQoW528DZLTsMnMxkCAjpWYa7gi+kSli2Qk645udwW4=; b=C69CTZCaQr0AT4Z+6y2njeSDlgATbEuN1IIzwv0sOVrxIgrV2yB64p5kJHzals19ev NmyuQjA62W46Kksqtm7h9ztWfSHcxhWY+g7HSTenWYbvRJKsUAOvnPAuq+PTGEwAcNK9 PWHj13jhnXzS12QiKZGPLL3UfY+390pd7a+xU= 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=VgAjHdbNsZAqU+3xETwfKR81+Mq05aQkbY+S5uJlv9HgxCkmJZuayMy65/Q1jUEFc4 CLlQjVToFIqP6fNNNFVYf+V1akD8Pr3QxaiCJVg2MA3gnAMEoD2HReg18d5Ik5Z2L8w2 M7Dg49HmQaylI/kwHhP6U6/8J1LGyZjtggNZw= Date: Fri, 8 May 2009 07:16:13 -0400 Subject: Re: Issue 7247 and 7248 From: Bran Selic To: Adam Neal Cc: Steve Cook , "uml2-rtf@omg.org" I see that Adam has raised the same concerns with this resolution proposal as have I in the reply ot Steve that I just posted. Apologies for the duplication, but I am wading through my e-mail backlog in FCFS fashion. Regards...Bran On Tue, May 5, 2009 at 11:48 AM, Adam Neal wrote: (Resending with modified Subject so the issue under discussion is more easily tracked) ----------------------------- Hi Steve, I have some issues with the proposed changes under section 8.3.3 (Connector). I don't agree with the proposed constraint [1] from 7247: "[1] A connector may have no more than one end that connects to a Port and does not also connect to a Part. end->select( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty())->size() <= 1" Consider the following diagram: r1 and r2 are non-behavior ports on the encapsulation shell of class: Capsule2 b1 and b2 are non-service behavior ports that are internal (private/protected) to Capsule2. A delegation connector between r1 and r2 is perfectly valid. What is the reasoning against allowing one to forward incoming requests directly as in the above diagram? The assembly connector between b1 and b2 allows the classifier to send itself internal messages to be handled by its owned classifier behavior. This is also a common for RT. My problem with [1] is that it disallows both these cases. I also feel that constraints [3] and [4] which are also proposed to be removed, provide justifiable guidance to users. What does it mean if we don't have these constraints? That ports which provide incompatible interfaces can be connected? This seems like something fundamental that should continue to be disallowed. I'm not sure how to handle the case where one is not using ports as we I don't believe we can connect to the lollipops/sockets (which is perhaps one reason to force the use of ports), but for connected ports, at least, it should be clear. May I suggest: [2] The required interfaces of any port at an end of a connector must be realized by the union of the provided interfaces of the ports at the other ends. Thanks, Adam Steve Cook Steve Cook 04/28/2009 06:20 AM To "uml2-rtf@omg.org" cc Subject Proposed component resolutions in Ballot 6 Drafts I have dropped a document with a large number of Component resolutions into Ballot 6 Drafts. The document is called UML 2.3 Resolution Components - 090427 Cook.doc and addresses the following issues: 6433, 7247, 7248, 7249, 7250, 7251, 7364, 8106, 8168, 8705, 8900, 9413, 9464, 9578, 9807, 10526, 10651, 12241, 12985, 13146. Many of these issues are very interdependent and concern mistaken or problematic notions like connectors wiring to interfaces, provided/required ports, and ball and socket notation. In order to help me do this and to help people to review it I have created a .convenience document. with all the changes marked and cross-referenced to issues. This is also in Ballot 6 Drafts and called 8Components.proposed.doc. Your comments would be much appreciated. Thanks -- Steve Content-Type: image/gif; name="graycol.gif" Content-ID: <2__=0ABBFF3EDFC53BB08f9e8a93df938@ca.ibm.com> X-Attachment-Id: 0.2 Content-Type: image/gif; name="1D483621.gif" Content-ID: <1__=0ABBFF3EDFC53BB08f9e8a93df938@ca.ibm.com> X-Attachment-Id: 0.1 Content-Type: image/gif; name="ecblank.gif" Content-ID: <4__=0ABBFF3EDFC53BB08f9e8a93df938@ca.ibm.com> X-Attachment-Id: 0.4 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=Kohb8As4jppxV391s5+KRlVB3J8xtKTH+mRfNRoqGjo=; b=qBH1uhWSOCgfJ1Q6SjWvfnqGTTFK+0okH7B2onrFTtZjKOwiA3oczZDb2Quu0O76up vcHR+Cyjki/PIBvTI+PuYSdVNLXliM4PaBit1Az82XlPAuR3TdunLZq7BIxwCUVsQGSW 7mZucb562b0G1JMndZHqSjFp15cZQriv+8XPs= 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=ISitfv5hv+pYXdFtgwrLStWr0Af1N4C/we+0gaNN05JcC7Dz9GDMm4rtHRLADojhqj zqb8n/zNnLYQn9z5quPPtF2YksGNgxCWSFkJo/SRfZOUmNQGcdTVj0RDT0VlqfmsL911 CZK1Jof8OYjfgrh0Egl4UV2C7aD+rp3Yotak4= Date: Fri, 8 May 2009 07:21:30 -0400 Subject: Re: Issue 7247 and 7248 From: Bran Selic To: Adam Neal Cc: Steve Cook , "uml2-rtf@omg.org" By "informal sketching" I meant simply that, when doing modeling, I should not have to put more information in a model than I care about. In this case, I was simply trying to say that I should not be forced to declare any required or provided interfaces for a port (although, of course, you can still do so if you want). This allows users to simply draw untyped ports and connectors between them and not be forced by the tool to define dummy ones just to satisfy the constraint. That's all. Cheers...Bran On Wed, May 6, 2009 at 8:31 PM, Adam Neal wrote: Hi, Bran, in regards your issue 10526, I agree that we shouldn't have constraints which disallow informal sketching. But were you suggesting that when we have a connector between ports, which do have provided/required interfaces, that we shouldn't ensure that those connections are well-formed? Perhaps I'm unclear about the 'informal sketching' issue, but I would expect this constraint (below) to exist mainly to help users validate models when they want to test its well-formedness. Steve, your provided resolution for the semantics of 8.3.3 includes the following (issue 7247): "A port may delegate to a set of ports on subordinate components. In that case, these subordinate ports must collectively offer the delegated functionality of the delegating port. " "The interface compatibility between ports that are connected enables an existing component in a system to be replaced by one that (minimally) offers the same set of services" I am suggesting that this constraining text continue to exist as a real constraint (which is what I believe [3] and [4] were trying to do). I agree that talking about 'union of interfaces' is perhaps ambiguous, rather we should talk in terms of the set of features of an interface. As you mentioned, determining compatibility of connected elements is a semantic variation point. Though I'd like to suggest that we try to define compatibility for connected ports, and leave the semantic variation point to describe connectors involving other elements. Your provided text already implies this compatibility of ports; and I quote "The interface compatibility between ports that are connected". Just to help visualize it, let's consider the simple case of a binary connector: where 'p*' is the set of features in the provided interfaces of the port, and 'r*' is the set of features in the required interfaces of a port. Note, normally when we talk about provided/required interfaces, we are discussing in terms of the 'external' side of a port which exposes these interfaces. But when we discuss the 'delegate' connector, it is important to note that it is actually connecting to the 'internal' side of the delegating port, where conceptually the provided/required interfaces are 'conjugated'; which is necessary so that the port can actually receive these delegate messages, and pass them on. Also, it should be noted that connecting to the inside of a port implies that its behavior=false; behavior=true would imply that the signal is essentially terminated and not delegated. Though, when we connect to the external side of a port, whether it has behavior or not is irrelevant. When we discuss an assembly connector, if a port with required set of (interface) features, 'r1', has a feature that is not compatible with any feature defined in p2, then this connection should be ill-formed. In terms of the delegate connector we must constrain it as you've said: "subordinate ports must collectively offer the delegated functionality of the delegating port.". i.e. r3 can require more than r4, but at minimum must require what r4 requires. If r4 requires a feature that r3 does not, then this too should be considered ill-formed. Similarly, p4 can provide more than p3, but at minimum it must provide what p3 provides. I believe this can all be handled by one constraint. Though special consideration must be given to delegate connectors connecting to the 'inside' of a delegating port such that the correct set of required/provided features are considered. So, I will suggest we add: The required set of (interface) features of a delegating port from the context of the delegating connector are derived from the set of features that exist in the port's provided interfaces. The provided set of (interface) features of a delegating port from the context of the delegating connector are derived from the set of features that exist in the port's required interfaces. And: [1] Each feature of each of the required interfaces of each port at an end of a connector must have at least one COMPATIBLE feature among the features of the provided interfaces of ports at the other ends. Note: I use 'COMPATIBLE' for lack of a better word, if there is one, and welcome any suggestions. Regards, -Adam P.S. Sorry to write this and run, but I will be unavailable as of tomorrow, and will not be able to respond until I return on May 18th Steve Cook Steve Cook 05/06/2009 05:06 AM To Adam Neal/Ottawa/IBM@IBMCA cc "uml2-rtf@omg.org" Subject RE: Issue 7247 and 7248 Adam I am happy to drop constraint [1] on the basis of this feedback and will do so. With regard to your comment about dropping the other constraints I refer you to Bran.s issue 10526: .The constraints defined for Connectors in the components chapter should be removed: they refer to "provided" and "required" ports (categories no longer supported in UML) but also force very stringent connection rules that get in the way of informal sketching type usage, since they require the explicit declaration of interfaces when doing structure modeling. These types of constraints should only be enforced through a profile.. Also the one you have proposed .[2] The required interfaces of any port at an end of a connector must be realized by the union of the provided interfaces of the ports at the other ends.. seems problematic to me. Do you mean .the union of the required interfaces of any port ... must be realized by the union of the provided interfaces ....? Or do you mean each of the required interfaces must be realized by some subset of the union of the provided interfaces? Or something else? In any case I don.t know what the union of a set of interfaces is. Plus I refer to the following statement in chapter 9: .What makes connectable elements compatible is a semantic variation point.. If it is a semantic variation point in chapter 9, why is it not a semantic variation point in chapter8? Given these three points it seems to me that the weight of the argument is strongly in favour of no additional constraints. -- Steve From: Adam Neal [mailto:Adam_Neal@ca.ibm.com] Sent: 05 May 2009 16:49 To: Steve Cook Cc: uml2-rtf@omg.org Subject: Issue 7247 and 7248 (Resending with modified Subject so the issue under discussion is more easily tracked) ----------------------------- Hi Steve, I have some issues with the proposed changes under section 8.3.3 (Connector). I don't agree with the proposed constraint [1] from 7247: "[1] A connector may have no more than one end that connects to a Port and does not also connect to a Part. end->select( e | e.role.oclIsKindOf(Port) and e.partWithPort.isEmpty())->size() <= 1" Consider the following diagram: r1 and r2 are non-behavior ports on the encapsulation shell of class: Capsule2 b1 and b2 are non-service behavior ports that are internal (private/protected) to Capsule2. A delegation connector between r1 and r2 is perfectly valid. What is the reasoning against allowing one to forward incoming requests directly as in the above diagram? The assembly connector between b1 and b2 allows the classifier to send itself internal messages to be handled by its owned classifier behavior. This is also a common for RT. My problem with [1] is that it disallows both these cases. I also feel that constraints [3] and [4] which are also proposed to be removed, provide justifiable guidance to users. What does it mean if we don't have these constraints? That ports which provide incompatible interfaces can be connected? This seems like something fundamental that should continue to be disallowed. I'm not sure how to handle the case where one is not using ports as we I don't believe we can connect to the lollipops/sockets (which is perhaps one reason to force the use of ports), but for connected ports, at least, it should be clear. May I suggest: [2] The required interfaces of any port at an end of a connector must be realized by the union of the provided interfaces of the ports at the other ends. Thanks, Adam Steve Cook Steve Cook 04/28/2009 06:20 AM To "uml2-rtf@omg.org" cc Subject Proposed component resolutions in Ballot 6 Drafts I have dropped a document with a large number of Component resolutions into Ballot 6 Drafts. The document is called UML 2.3 Resolution Components - 090427 Cook.doc and addresses the following issues: 6433, 7247, 7248, 7249, 7250, 7251, 7364, 8106, 8168, 8705, 8900, 9413, 9464, 9578, 9807, 10526, 10651, 12241, 12985, 13146. Many of these issues are very interdependent and concern mistaken or problematic notions like connectors wiring to interfaces, provided/required ports, and ball and socket notation. In order to help me do this and to help people to review it I have created a .convenience document. with all the changes marked and cross-referenced to issues. This is also in Ballot 6 Drafts and called 8Components.proposed.doc. Your comments would be much appreciated. Thanks -- Steve Content-Type: image/gif; name="ecblank.gif" Content-ID: <4__=0ABBFF3DDFE400FE8f9e8a93df938@ca.ibm.com> X-Attachment-Id: 0.4 Content-Type: image/gif; name="graycol.gif" Content-ID: <2__=0ABBFF3DDFE400FE8f9e8a93df938@ca.ibm.com> X-Attachment-Id: 0.2 Content-Type: image/gif; name="20508167.gif" Content-ID: <1__=0ABBFF3DDFE400FE8f9e8a93df938@ca.ibm.com> X-Attachment-Id: 0.1 Content-Type: image/gif; name="20729430.gif" Content-ID: <5__=0ABBFF3DDFE400FE8f9e8a93df938@ca.ibm.com> X-Attachment-Id: 0.5 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 Connector - "provided Port" and "required Port" not defined Constraint 1, "[1] A delegation connector must only be defined between used Interfaces or Ports of the same kind, e.g. between two provided Ports or between two required Ports." uses the concepts "provided Port" and "required Port". Neither of them is defined in the spec. Furthermore, a Connector is not expected to be defined between Interfaces, but an Association is. A Connector is defined between ConnectableElements whose specializations are Property, Port, Parameter, and Variable, but not Interface. I suggest to replace Constraint [1] with "[1] A delegation connector must only be defined between a ConnectableElement (i.e. a Port) of the component and a ConnectableElement (i.e. a Property or a Port) of one of its internal parts."