Issue 10474: Connector contract is inflexible (uml2-rtf) Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: Connector contract is inflexible and cannot bind connector ends to parts in the contract behavior. A Connector can have a contract which is a Behavior which specifies the valid interaction pattern across the connector. The Behavior could be an Interaction, Activity, StateMachine, ProtocolStateMachine, or OpaqueBehavior. However, the parts in the Behavior (lifeliines. activity partitions, target input pins, variables, etc.) cannot be bound to the ports at the end of the connector. So it is difficult to understand what part participating ports play in the contract beahvior. Another problem is that the may be more than one interaction between the parts at the connector ends representing different conversations between the same parties over the same connector. This would require more than one behavior for the contract in order to describe each interaction. Instead, the contract for a connector should be a CollaborationUse. The connectorEnds would then be bound to the roles they play in that contract. The Collaboration of the CollaborationUse can contain multiple ownedBehaviors which represent the interaction protocols between the roles. Parts playing these roles (as indicated by a CollaborationUse) would have to interact in a manner consistent with the corresponding Collaboration ownedBehavior. (These can match by name, but we may want to consider an extension that allowed bindings between operations of the parts and behavior of the collaboration to allow more flexible contracts). The interactions between connected consumers and providers instances are initiated by one party or the other (may not be the same for all such interactions). The provider will typically define the protocol consumers must follow in order to use the provided capabilities. One way to model these protocols is to set the type of the Port providing the capability to the Collaboration defining the protocol. Then the type of the CollaborationUse for any Connector connected to that port would be the type of the Port. Resolution: Revised Text: Actions taken: November 29, 2006: received issue Discussion: End of Annotations:===== c: Branislav Selic Subject: UML2: Connector contract is inflexible and cannot bind connector ends to parts in the contract behavior X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Jim Amsden Date: Wed, 29 Nov 2006 18:39:31 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 11/29/2006 16:39:48, Serialize complete at 11/29/2006 16:39:48 A Connector can have a contract which is a Behavior which specifies the valid interaction pattern across the connector. The Behavior could be an Interaction, Activity, StateMachine, ProtocolStateMachine, or OpaqueBehavior. However, the parts in the Behavior (lifeliines. activity partitions, target input pins, variables, etc.) cannot be bound to the ports at the end of the connector. So it is difficult to understand what part participating ports play in the contract beahvior. Another problem is that the may be more than one interaction between the parts at the connector ends representing different conversations between the same parties over the same connector. This would require more than one behavior for the contract in order to describe each interaction. Instead, the contract for a connector should be a CollaborationUse. The connectorEnds would then be bound to the roles they play in that contract. The Collaboration of the CollaborationUse can contain multiple ownedBehaviors which represent the interaction protocols between the roles. Parts playing these roles (as indicated by a CollaborationUse) would have to interact in a manner consistent with the corresponding Collaboration ownedBehavior. (These can match by name, but we may want to consider an extension that allowed bindings between operations of the parts and behavior of the collaboration to allow more flexible contracts). The interactions between connected consumers and providers instances are initiated by one party or the other (may not be the same for all such interactions). The provider will typically define the protocol consumers must follow in order to use the provided capabilities. One way to model these protocols is to set the type of the Port providing the capability to the Collaboration defining the protocol. Then the type of the CollaborationUse for any Connector connected to that port would be the type of the Port.