Issue 13452: Section 9.3.4 Collaboration Use, 2nd constraint creates unneces (uml2-rtf) Source: Dell Technologies (Mr. George Ericson, ericson.george(at)emc.com) Nature: Uncategorized Issue Severity: Summary: Assuming one Collaboration represents mandatory features and another Collaboration wants to extend that. It seems natural to express only the differences in the second Collaboration and to use roleBinding to between properties of the extending Collaboration to properties of a CollaborationUse of the first. The implication is that properties of the first collaboration are included as part of the second collaboration, since the CollaborationUse is essentially an instantiation of the first Collaboration in the context of the second. The roleBindings indicate were instances of the properties of first are constrained to be instances of the second Collaboration. This usage would require that the 2nd constraint be modified and that properties of the CollaborationUse of the first Collaboration are interpreted as being incorporated into the second Collaboration except when there is a roleBinding between the properties of the first and second Collaborations. Resolution: Revised Text: Actions taken: January 30, 2009: received issue Discussion: End of Annotations:===== m: ericson_george@emc.com Subject: Section 9.3.4 Collaboration Use, 2nd constraint creates unnecessarily complex diagraming and modeling. Date: Fri, 30 Jan 2009 14:41:07 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Section 9.3.4 Collaboration Use, 2nd constraint creates unnecessarily complex diagraming and modeling. Thread-Index: AcmDErI6zv++QqFVRYqnWknF2QZwyQ== To: X-OriginalArrivalTime: 30 Jan 2009 19:41:08.0722 (UTC) FILETIME=[B2AECD20:01C98312] X-EMM-EM: Active Assuming one Collaboration represents mandatory features and another Collaboration wants to extend that. It seems natural to express only the differences in the second Collaboration and to use roleBinding to between properties of the extending Collaboration to properties of a CollaborationUse of the first. The implication is that properties of the first collaboration are included as part of the second collaboration, since the CollaborationUse is essentially an instantiation of the first Collaboration in the context of the second. The roleBindings indicate were instances of the properties of first are constrained to be instances of the second Collaboration. This usage would require that the 2nd constraint be modified and that properties of the CollaborationUse of the first Collaboration are interpreted as being incorporated into the second Collaboration except when there is a roleBinding between the properties of the first and second Collaborations. Subject: Issue 13452 Date: Fri, 12 Mar 2010 16:16:20 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 13452 Thread-Index: AcrCKUMJl73lSH8JQ7KyqW+cJ+Sf+A== From: To: X-OriginalArrivalTime: 12 Mar 2010 21:16:21.0547 (UTC) FILETIME=[438137B0:01CAC229] X-EMM-EM: Active This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. To see the scope of this problem, consider what SuperStructure would look like if you did not have PackageMerge. Please implement a solution to the problem of efficiently representing the aspects of a containing Classifier via merging the requirements of CollaborationUses: One suggestion for implementation is: · Add attribute to CollaborationUse asserting that all requirements of the Collaboration that defines its type are incorporated into the Classifier that has a collaboratioUse relationship to it. Additionally that instances of ConnectableElements that have a collaborationRole relationship to Properties defined by the CollaborationUse are subsets of instances of the Properties of the CollaborationUse. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=mjoZGI0VKOG0VvphNsrN+T6u1/D4zeHBhqg+jaOK/JU=; b=ZAfRYxVIvKTYUFjZ/bN98RW+htQ0eVXTdRolcEFyfFOOBth9OGnSukq3cO8B21lHFU 8fPdB+GBbOEzJSF/MA2RxMpwMWg2kJjQCwNHIQ4Pj/kyR5CEYCaXxROkQJP5AuNr1dr+ 8i7F5rLOVCQFAdbHUQRC941XZk1HZ0iHNB808= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=uJ4yqYGNb4g3Z9ufPwHqMzm7+ssIieLcfLLJ5+X3Ayc0bI0wB0eHRKTSL5e/3yktfk +FhGEjkfhSy0yzwNGVHpScET+dGEtVQcHQ0m15Weds/0NGTH0bwcg51RBg5ONo+ErxUt wo9+FJPkzahpfTS0mQ9c2RC3pSOXJIscIr+fY= Sender: bran.selic@gmail.com From: Bran Selic Date: Sat, 13 Mar 2010 07:00:24 -0500 X-Google-Sender-Auth: 68110c127637eaf1 Subject: Re: Issue 13452 To: ericson_george@emc.com Cc: uml2-rtf@omg.org George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran To: Bran Selic Cc: bran.selic@gmail.com, ericson_george@emc.com, uml2-rtf@omg.org Subject: Re: Issue 13452 X-KeepSent: 454920D6:74321A31-852576E5:004708ED; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Sat, 13 Mar 2010 08:03:18 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 03/13/2010 06:03:20, Serialize complete at 03/13/2010 06:03:20 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran Subject: RE: Issue 13452 Date: Sat, 13 Mar 2010 21:53:57 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 13452 Thread-Index: AcrCrbDNrvtWgjWLQvWl0idu7Fd2GwAaCiXw From: To: , Cc: , X-OriginalArrivalTime: 14 Mar 2010 02:54:09.0587 (UTC) FILETIME=[9E9C7030:01CAC321] X-EMM-EM: Active Jim, Bran, Let me back up and explain the use case I.m trying to solve. We have a Model that includes some 1000 Classes and 600 AssociationClasses. Note, this model currently does not use any simple Associations. The AssociationClasses own their AssociationEnds. For various uses, we want to select some number of Classes and related AssociationClasses and specify implementation requirements. The UML Collaboration seems most amenable to this, but we have some issues. Each of these Collaborations then represents a pattern, or assembly, specification that an implementation must conform to if it claims support for the use represented by the Collaboration. The implementation can be modeled as a Component. In general, there will be a top level Collaboration that an implementation of a Component conforms to. That top level Collaboration is often built up from one or more sub Collaborations. We want to use this modeling technique to SNIA.s SMI-S profiles and DMTF.s Server Management profiles. So, the sub collaborations will often be nested 3-5 layers deep. In other words, these get very complex. Our problem is that we want to keep the presentation and representation as simple as possible. We are looking to do the following: · Collaborations represent a sub model together with implementation requirements and constraints. These are additive to the requirements of the schema. · Classes in our model are represented by Properties of a Collaboration, with specific requirements and constraints on the methods and properties and cardinality of instances of the Class added to the Collaboration Property. · AssociationClasses are represented by Connections of a Collaboration, with specific requirements and constraints on the methods and properties and multiplicities of the AssociationClass added to the Collaboration Connection. · Sub Collaborations are represented by CollaborationUses. Several problems with this approach have been pointed out: 1) We read the constraint mentioned in the issue 13452 would require that each Collaboration explicitly create Properties to represent every Property of all sub Collaborations, represented by CollaborationUses. This is recursive and while we understand that all of these Properties don.t need to be shown in related CompositeStructure diagrams, never-the-less it means that the model contains a large number of Properties that could be implied. While the semantics are slightly different, this is very similar to the same problem solved by PackageMerge that implies the existence of the incorporated Elements, without requiring them all to be modeled in the incorporating Package. a. Where we explicitly create a RoleBinding between a Property and a corresponding Property in a CollaborationUse, we expect that the behaviors, requirements, and constraints on the Property create a subset of the Property in the CollaborationUse. b. Where we explicitly do not create RoleBindings to a Property of a CollaborationUse, we expect that the behaviors, requirements and constraints of that Property are incorporated into the Collaboration that specifies the CollaborationUse. It would be ideal if this is already what you intend for the semantics of CollaborationUse. If not, perhaps a boolean attribute could be added to the CollaborationUse that specifies this behavior. 2) We read the model for Connector to allow the type to be an AssociationClass, but this is somewhat controversial and not well-supported by the UML tool industry. 3) We read RoleBinding as an alternative representation of Subset relationship between properties. However, subsetting is not currently directly supported between properties within a Collaboration. In our models, a common case where this occurs is where we want to include but Classes and Sub Classes of that class into a Collaboration. Often with additional Connections. It is possible to recursively reference a Collaboration as a CollaborationUse to solve this problem, but that seems somewhat awkward. The Generalization relationship would be a natural addition to the Collaboration Model to represent this. For now, Issue 1 is the primary show-stopper. Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, March 13, 2010 8:03 AM To: Bran Selic Cc: bran.selic@gmail.com; Ericson, George; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=J8yrZFPcVV2P5ERT7ZzRg23ChcRYPMQmNbz/vj8kWZI=; b=eR084jQvqDu/edMHaR19WhEmBSiW/2ByoVwhVjgQOWeRtUxIlgB+mGvyjCPAN/J7ME kBZdjhOmPUEC9ldeR6R/YDcm3YHAVSEH0gAnpf0d+QRK1s8vbOuXAZNgPXoad0SM8LHU KxHt7GfZE7YA/JEtL44lvhE9qpNRQVDexoYW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=PJhEVOEQYjBxshI9HogNbf1C/v4HQv8viQNcd7f0d/cYuz/d7cGjKlKaxSSQTDTQUo nt7ATC/UwZyUas1xxMopEZQI4DpvUrYBAaVULkAeI36vhwb3U6atM4j9B+fwJJOhhdB8 PunAZKBYxbNyYsbMYannXnwwIwfIJY10PYaaQ= Sender: bran.selic@gmail.com From: Bran Selic Date: Sun, 14 Mar 2010 06:51:22 -0500 X-Google-Sender-Auth: 6cbf390a9d6133df Subject: Re: Issue 13452 To: Jim Amsden Cc: ericson_george@emc.com, uml2-rtf@omg.org Thanks, Jim. However, I am still mystified by the statement that it is the collaboration USE is a "type system". I can see that a collaboration, being a kind of Classifier, can be a type (which is not the same thing as a "type system"). So, I am not sure if this is merely a problem in the way George formulated his statement or whether there is something deeper behind it. BTW, I am not sure that the solution you folks used in SoaML is necessary. That is, I don't see the need to add the "isStrict" attribute given that type compatibility is a semantic variation point in UML. Could you not have gotten by with overriding the default "Classifier::confromsTo" operation? (Note that Classifier already does that by redefining Type::conformsTo()). Cheers...Bran On Sat, Mar 13, 2010 at 8:03 AM, Jim Amsden wrote: Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran Subject: Re: Issue 13452 Date: Sun, 14 Mar 2010 11:14:23 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 13452 Thread-Index: AcrDbLqyTJm1IwSxSveJpxDzBtvdQAAHEzaU From: To: , Cc: X-OriginalArrivalTime: 14 Mar 2010 15:14:25.0309 (UTC) FILETIME=[0871C4D0:01CAC389] X-EMM-EM: Active Bran, My statement was badly formed. The issues that I'm concerned about are better formulated in the reply I send yesterday. G -------------------------------------------------------------------------------- From: bran.selic@gmail.com To: Jim Amsden Cc: Ericson, George; uml2-rtf@omg.org Sent: Sun Mar 14 07:51:22 2010 Subject: Re: Issue 13452 Thanks, Jim. However, I am still mystified by the statement that it is the collaboration USE is a "type system". I can see that a collaboration, being a kind of Classifier, can be a type (which is not the same thing as a "type system"). So, I am not sure if this is merely a problem in the way George formulated his statement or whether there is something deeper behind it. BTW, I am not sure that the solution you folks used in SoaML is necessary. That is, I don't see the need to add the "isStrict" attribute given that type compatibility is a semantic variation point in UML. Could you not have gotten by with overriding the default "Classifier::confromsTo" operation? (Note that Classifier already does that by redefining Type::conformsTo()). Cheers...Bran On Sat, Mar 13, 2010 at 8:03 AM, Jim Amsden wrote: Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings.  Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? ÂÂHowever, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran To: Cc: selic@acm.org, uml2-rtf@omg.org Subject: Re: Issue 13452 X-KeepSent: 394376CC:DAFF4C5E-852576E6:006C2BAF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Sun, 14 Mar 2010 15:43:41 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 03/14/2010 13:43:38, Serialize complete at 03/14/2010 13:43:38 Bran Property isStrict is something a modeler can set - to indicate whether the parts are required to be type compatible with the collaboration roles they are bound to through a collaboration use, or if these role bindings are intended to be informal information. Overriding conformsTo would be at the metamodel level, not the model level. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS Cc: Date: 03/14/2010 11:17 AM Subject: Re: Issue 13452 -------------------------------------------------------------------------------- Bran, My statement was badly formed. The issues that I'm concerned about are better formulated in the reply I send yesterday. G -------------------------------------------------------------------------------- From: bran.selic@gmail.com To: Jim Amsden Cc: Ericson, George; uml2-rtf@omg.org Sent: Sun Mar 14 07:51:22 2010 Subject: Re: Issue 13452 Thanks, Jim. However, I am still mystified by the statement that it is the collaboration USE is a "type system". I can see that a collaboration, being a kind of Classifier, can be a type (which is not the same thing as a "type system"). So, I am not sure if this is merely a problem in the way George formulated his statement or whether there is something deeper behind it. BTW, I am not sure that the solution you folks used in SoaML is necessary. That is, I don't see the need to add the "isStrict" attribute given that type compatibility is a semantic variation point in UML. Could you not have gotten by with overriding the default "Classifier::confromsTo" operation? (Note that Classifier already does that by redefining Type::conformsTo()). Cheers...Bran On Sat, Mar 13, 2010 at 8:03 AM, Jim Amsden wrote: Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran Subject: SoaML isStrict, was (RE: Issue 13452) Date: Sun, 14 Mar 2010 17:11:35 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SoaML isStrict, was (RE: Issue 13452) Thread-Index: AcrDrqfuEYEI/ryXSjm9ezVXu7CE+wACnPPQ From: To: Cc: , X-OriginalArrivalTime: 14 Mar 2010 21:11:36.0640 (UTC) FILETIME=[EE835C00:01CAC3BA] X-EMM-EM: Active Jim, I.m assuming that isStrict, as you are using it here, refers to the CollaborationUse Stereotype attribute in SoaML. If true, it is not relevant to 13452. However, I.m interested to see examples where the type of the part is not compatible with that of the role it is bound to, but where it still fulfills the behavioral contract of the role. Does the need for this come about because of deficiencies in how some SOA models use XML? George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Sunday, March 14, 2010 3:44 PM To: Ericson, George Cc: selic@acm.org; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran Property isStrict is something a modeler can set - to indicate whether the parts are required to be type compatible with the collaboration roles they are bound to through a collaboration use, or if these role bindings are intended to be informal information. Overriding conformsTo would be at the metamodel level, not the model level. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS Cc: Date: 03/14/2010 11:17 AM Subject: Re: Issue 13452 -------------------------------------------------------------------------------- Bran, My statement was badly formed. The issues that I'm concerned about are better formulated in the reply I send yesterday. G -------------------------------------------------------------------------------- From: bran.selic@gmail.com To: Jim Amsden Cc: Ericson, George; uml2-rtf@omg.org Sent: Sun Mar 14 07:51:22 2010 Subject: Re: Issue 13452 Thanks, Jim. However, I am still mystified by the statement that it is the collaboration USE is a "type system". I can see that a collaboration, being a kind of Classifier, can be a type (which is not the same thing as a "type system"). So, I am not sure if this is merely a problem in the way George formulated his statement or whether there is something deeper behind it. BTW, I am not sure that the solution you folks used in SoaML is necessary. That is, I don't see the need to add the "isStrict" attribute given that type compatibility is a semantic variation point in UML. Could you not have gotten by with overriding the default "Classifier::confromsTo" operation? (Note that Classifier already does that by redefining Type::conformsTo()). Cheers...Bran On Sat, Mar 13, 2010 at 8:03 AM, Jim Amsden wrote: Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran To: Cc: selic@acm.org, uml2-rtf@omg.org Subject: Re: SoaML isStrict, was (RE: Issue 13452) X-KeepSent: 2E7D0D90:26C61502-852576E7:000373CD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Sun, 14 Mar 2010 20:40:57 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 03/14/2010 18:40:58, Serialize complete at 03/14/2010 18:40:58 isStrict is just a means of allowing the modeler to indicate that the parts don't have to be type or behaviorally compatible with the roles they are bound to - possibly because the roles are under specified, perhaps representing an informal sketch of an architectural patterns, or a requirements statement. This would be similar to use case realization, but providing a bit more specific relationship between parts and roles. There is no further semantic associated with isStrict=false. isStrict=true means the same as currently for UML2. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , Date: 03/14/2010 05:15 PM Subject: SoaML isStrict, was (RE: Issue 13452) -------------------------------------------------------------------------------- Jim, Iâm assuming that isStrict, as you are using it here, refers to the CollaborationUse Stereotype attribute in SoaML. If true, it is not relevant to 13452. However, Iâm interested to see examples where the type of the part is not compatible with that of the role it is bound to, but where it still fulfills the behavioral contract of the role. Does the need for this come about because of deficiencies in how some SOA models use XML? George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Sunday, March 14, 2010 3:44 PM To: Ericson, George Cc: selic@acm.org; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran Property isStrict is something a modeler can set - to indicate whether the parts are required to be type compatible with the collaboration roles they are bound to through a collaboration use, or if these role bindings are intended to be informal information. Overriding conformsTo would be at the metamodel level, not the model level. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS Cc: Date: 03/14/2010 11:17 AM Subject: Re: Issue 13452 -------------------------------------------------------------------------------- Bran, My statement was badly formed. The issues that I'm concerned about are better formulated in the reply I send yesterday. G -------------------------------------------------------------------------------- From: bran.selic@gmail.com To: Jim Amsden Cc: Ericson, George; uml2-rtf@omg.org Sent: Sun Mar 14 07:51:22 2010 Subject: Re: Issue 13452 Thanks, Jim. However, I am still mystified by the statement that it is the collaboration USE is a "type system". I can see that a collaboration, being a kind of Classifier, can be a type (which is not the same thing as a "type system"). So, I am not sure if this is merely a problem in the way George formulated his statement or whether there is something deeper behind it. BTW, I am not sure that the solution you folks used in SoaML is necessary. That is, I don't see the need to add the "isStrict" attribute given that type compatibility is a semantic variation point in UML. Could you not have gotten by with overriding the default "Classifier::confromsTo" operation? (Note that Classifier already does that by redefining Type::conformsTo()). Cheers...Bran On Sat, Mar 13, 2010 at 8:03 AM, Jim Amsden wrote: Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran To: Cc: bran.selic@gmail.com, ericson_george@emc.com, selic@acm.org, uml2-rtf@omg.org Subject: RE: Issue 13452 X-KeepSent: D4868397:9E4C7725-852576E8:0069C710; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Tue, 16 Mar 2010 15:20:12 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 03/16/2010 16:20:11, Serialize complete at 03/16/2010 16:20:11 SoaML extends UML and is free to define whatever semantics it requires - as is any other specification. The isStrict property provides additional flexibility in UML models. If isStrict is true, then the normal UML semantics apply. If it is false, then the SoaML extension applies and the collaboration use role bindings don't need to be complete or type compatible. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS, Cc: , Date: 03/16/2010 05:01 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- I thought about applying the same idea as used by SoaML isStrict to a CollaborationUse stereotype as a means to extend the UML model to cover our case. We could add an isMerge attribute to a stereotype that extends CollaborationUse. However, I am concerned that this approach is not consistent with the UML model, since it seems to violate the UML CollaborationUse constraint: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the classifier or operation. (Similarly, I think the SoaML isStrict attribute of a CollaborationUse stereotype violates the UML model type constraint.) I would appreciate guidance on this topic. Thanks, George From: Ericson, George Sent: Saturday, March 13, 2010 9:54 PM To: Jim Amsden; Bran Selic Cc: bran.selic@gmail.com; uml2-rtf@omg.org Subject: RE: Issue 13452 Jim, Bran, Let me back up and explain the use case Iâm trying to solve. We have a Model that includes some 1000 Classes and 600 AssociationClasses. Note, this model currently does not use any simple Associations. The AssociationClasses own their AssociationEnds. For various uses, we want to select some number of Classes and related AssociationClasses and specify implementation requirements. The UML Collaboration seems most amenable to this, but we have some issues. Each of these Collaborations then represents a pattern, or assembly, specification that an implementation must conform to if it claims support for the use represented by the Collaboration. The implementation can be modeled as a Component. In general, there will be a top level Collaboration that an implementation of a Component conforms to. That top level Collaboration is often built up from one or more sub Collaborations. We want to use this modeling technique to SNIAâs SMI-S profiles and DMTFâs Server Management profiles. So, the sub collaborations will often be nested 3-5 layers deep. In other words, these get very complex. Our problem is that we want to keep the presentation and representation as simple as possible. We are looking to do the following: · Collaborations represent a sub model together with implementation requirements and constraints. These are additive to the requirements of the schema. · Classes in our model are represented by Properties of a Collaboration, with specific requirements and constraints on the methods and properties and cardinality of instances of the Class added to the Collaboration Property. · AssociationClasses are represented by Connections of a Collaboration, with specific requirements and constraints on the methods and properties and multiplicities of the AssociationClass added to the Collaboration Connection. · Sub Collaborations are represented by CollaborationUses. Several problems with this approach have been pointed out: 1) We read the constraint mentioned in the issue 13452 would require that each Collaboration explicitly create Properties to represent every Property of all sub Collaborations, represented by CollaborationUses. This is recursive and while we understand that all of these Properties donât need to be shown in related CompositeStructure diagrams, never-the-less it means that the model contains a large number of Properties that could be implied. While the semantics are slightly different, this is very similar to the same problem solved by PackageMerge that implies the existence of the incorporated Elements, without requiring them all to be modeled in the incorporating Package. a. Where we explicitly create a RoleBinding between a Property and a corresponding Property in a CollaborationUse, we expect that the behaviors, requirements, and constraints on the Property create a subset of the Property in the CollaborationUse. b. Where we explicitly do not create RoleBindings to a Property of a CollaborationUse, we expect that the behaviors, requirements and constraints of that Property are incorporated into the Collaboration that specifies the CollaborationUse. It would be ideal if this is already what you intend for the semantics of CollaborationUse. If not, perhaps a boolean attribute could be added to the CollaborationUse that specifies this behavior. 2) We read the model for Connector to allow the type to be an AssociationClass, but this is somewhat controversial and not well-supported by the UML tool industry. 3) We read RoleBinding as an alternative representation of Subset relationship between properties. However, subsetting is not currently directly supported between properties within a Collaboration. In our models, a common case where this occurs is where we want to include but Classes and Sub Classes of that class into a Collaboration. Often with additional Connections. It is possible to recursively reference a Collaboration as a CollaborationUse to solve this problem, but that seems somewhat awkward. The Generalization relationship would be a natural addition to the Collaboration Model to represent this. For now, Issue 1 is the primary show-stopper. Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, March 13, 2010 8:03 AM To: Bran Selic Cc: bran.selic@gmail.com; Ericson, George; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran Subject: RE: Issue 13452 Date: Tue, 16 Mar 2010 16:53:57 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 13452 Thread-Index: AcrCrbDNrvtWgjWLQvWl0idu7Fd2GwAaCiXwAIyzVoA= From: To: , , Cc: , X-OriginalArrivalTime: 16 Mar 2010 20:53:58.0586 (UTC) FILETIME=[CCB0A1A0:01CAC54A] X-EMM-EM: Active I thought about applying the same idea as used by SoaML isStrict to a CollaborationUse stereotype as a means to extend the UML model to cover our case. We could add an isMerge attribute to a stereotype that extends CollaborationUse. However, I am concerned that this approach is not consistent with the UML model, since it seems to violate the UML CollaborationUse constraint: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the classifier or operation. (Similarly, I think the SoaML isStrict attribute of a CollaborationUse stereotype violates the UML model type constraint.) I would appreciate guidance on this topic. Thanks, George From: Ericson, George Sent: Saturday, March 13, 2010 9:54 PM To: Jim Amsden; Bran Selic Cc: bran.selic@gmail.com; uml2-rtf@omg.org Subject: RE: Issue 13452 Jim, Bran, Let me back up and explain the use case I.m trying to solve. We have a Model that includes some 1000 Classes and 600 AssociationClasses. Note, this model currently does not use any simple Associations. The AssociationClasses own their AssociationEnds. For various uses, we want to select some number of Classes and related AssociationClasses and specify implementation requirements. The UML Collaboration seems most amenable to this, but we have some issues. Each of these Collaborations then represents a pattern, or assembly, specification that an implementation must conform to if it claims support for the use represented by the Collaboration. The implementation can be modeled as a Component. In general, there will be a top level Collaboration that an implementation of a Component conforms to. That top level Collaboration is often built up from one or more sub Collaborations. We want to use this modeling technique to SNIA.s SMI-S profiles and DMTF.s Server Management profiles. So, the sub collaborations will often be nested 3-5 layers deep. In other words, these get very complex. Our problem is that we want to keep the presentation and representation as simple as possible. We are looking to do the following: · Collaborations represent a sub model together with implementation requirements and constraints. These are additive to the requirements of the schema. · Classes in our model are represented by Properties of a Collaboration, with specific requirements and constraints on the methods and properties and cardinality of instances of the Class added to the Collaboration Property. · AssociationClasses are represented by Connections of a Collaboration, with specific requirements and constraints on the methods and properties and multiplicities of the AssociationClass added to the Collaboration Connection. · Sub Collaborations are represented by CollaborationUses. Several problems with this approach have been pointed out: 1) We read the constraint mentioned in the issue 13452 would require that each Collaboration explicitly create Properties to represent every Property of all sub Collaborations, represented by CollaborationUses. This is recursive and while we understand that all of these Properties don.t need to be shown in related CompositeStructure diagrams, never-the-less it means that the model contains a large number of Properties that could be implied. While the semantics are slightly different, this is very similar to the same problem solved by PackageMerge that implies the existence of the incorporated Elements, without requiring them all to be modeled in the incorporating Package. a. Where we explicitly create a RoleBinding between a Property and a corresponding Property in a CollaborationUse, we expect that the behaviors, requirements, and constraints on the Property create a subset of the Property in the CollaborationUse. b. Where we explicitly do not create RoleBindings to a Property of a CollaborationUse, we expect that the behaviors, requirements and constraints of that Property are incorporated into the Collaboration that specifies the CollaborationUse. It would be ideal if this is already what you intend for the semantics of CollaborationUse. If not, perhaps a boolean attribute could be added to the CollaborationUse that specifies this behavior. 2) We read the model for Connector to allow the type to be an AssociationClass, but this is somewhat controversial and not well-supported by the UML tool industry. 3) We read RoleBinding as an alternative representation of Subset relationship between properties. However, subsetting is not currently directly supported between properties within a Collaboration. In our models, a common case where this occurs is where we want to include but Classes and Sub Classes of that class into a Collaboration. Often with additional Connections. It is possible to recursively reference a Collaboration as a CollaborationUse to solve this problem, but that seems somewhat awkward. The Generalization relationship would be a natural addition to the Collaboration Model to represent this. For now, Issue 1 is the primary show-stopper. Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, March 13, 2010 8:03 AM To: Bran Selic Cc: bran.selic@gmail.com; Ericson, George; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran Subject: Re: Issue 13452 Date: Tue, 16 Mar 2010 20:59:41 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 13452 Thread-Index: AcrFVumRxToCyM7yRYGQ2p8o3R9efwAFjai7 From: To: Cc: , , X-OriginalArrivalTime: 17 Mar 2010 00:59:43.0013 (UTC) FILETIME=[210DA550:01CAC56D] X-EMM-EM: Active The reason this makes me uncomfortable is that we define extension to require conformance to the extended element. The definition you are using implies that conformance is not a requirement. Isn't this at odds with clause 18.1.2 Extensibility that asserts: "It is not possible to take away any constraints that apply to a metamodel such as UML using a profile..." [gme: and thus a stereotype] George -------------------------------------------------------------------------------- From: Jim Amsden To: Ericson, George Cc: bran.selic@gmail.com ; Ericson, George; selic@acm.org ; uml2-rtf@omg.org Sent: Tue Mar 16 15:20:12 2010 Subject: RE: Issue 13452 SoaML extends UML and is free to define whatever semantics it requires - as is any other specification. The isStrict property provides additional flexibility in UML models. If isStrict is true, then the normal UML semantics apply. If it is false, then the SoaML extension applies and the collaboration use role bindings don't need to be complete or type compatible. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS, Cc: , Date: 03/16/2010 05:01 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- I thought about applying the same idea as used by SoaML isStrict to a CollaborationUse stereotype as a means to extend the UML model to cover our case. We could add an isMerge attribute to a stereotype that extends CollaborationUse. However, I am concerned that this approach is not consistent with the UML model, since it seems to violate the UML CollaborationUse constraint: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the classifier or operation. (Similarly, I think the SoaML isStrict attribute of a CollaborationUse stereotype violates the UML model type constraint.) I would appreciate guidance on this topic. Thanks, George From: Ericson, George Sent: Saturday, March 13, 2010 9:54 PM To: Jim Amsden; Bran Selic Cc: bran.selic@gmail.com; uml2-rtf@omg.org Subject: RE: Issue 13452 Jim, Bran, Let me back up and explain the use case Iâm trying to solve. We have a Model that includes some 1000 Classes and 600 AssociationClasses. Note, this model currently does not use any simple Associations. The AssociationClasses own their AssociationEnds. For various uses, we want to select some number of Classes and related AssociationClasses and specify implementation requirements. The UML Collaboration seems most amenable to this, but we have some issues. Each of these Collaborations then represents a pattern, or assembly, specification that an implementation must conform to if it claims support for the use represented by the Collaboration. The implementation can be modeled as a Component. In general, there will be a top level Collaboration that an implementation of a Component conforms to. That top level Collaboration is often built up from one or more sub Collaborations. We want to use this modeling technique to SNIAâs SMI-S profiles and DMTFâs Server Management profiles. So, the sub collaborations will often be nested 3-5 layers deep. In other words, these get very complex. Our problem is that we want to keep the presentation and representation as simple as possible. We are looking to do the following: · Collaborations represent a sub model together with implementation requirements and constraints. These are additive to the requirements of the schema. · Classes in our model are represented by Properties of a Collaboration, with specific requirements and constraints on the methods and properties and cardinality of instances of the Class added to the Collaboration Property. · AssociationClasses are represented by Connections of a Collaboration, with specific requirements and constraints on the methods and properties and multiplicities of the AssociationClass added to the Collaboration Connection. · Sub Collaborations are represented by CollaborationUses. Several problems with this approach have been pointed out: 1) We read the constraint mentioned in the issue 13452 would require that each Collaboration explicitly create Properties to represent every Property of all sub Collaborations, represented by CollaborationUses. This is recursive and while we understand that all of these Properties donât need to be shown in related CompositeStructure diagrams, never-the-less it means that the model contains a large number of Properties that could be implied. While the semantics are slightly different, this is very similar to the same problem solved by PackageMerge that implies the existence of the incorporated Elements, without requiring them all to be modeled in the incorporating Package. a. Where we explicitly create a RoleBinding between a Property and a corresponding Property in a CollaborationUse, we expect that the behaviors, requirements, and constraints on the Property create a subset of the Property in the CollaborationUse. b. Where we explicitly do not create RoleBindings to a Property of a CollaborationUse, we expect that the behaviors, requirements and constraints of that Property are incorporated into the Collaboration that specifies the CollaborationUse. It would be ideal if this is already what you intend for the semantics of CollaborationUse. If not, perhaps a boolean attribute could be added to the CollaborationUse that specifies this behavior. 2) We read the model for Connector to allow the type to be an AssociationClass, but this is somewhat controversial and not well-supported by the UML tool industry. 3) We read RoleBinding as an alternative representation of Subset relationship between properties. However, subsetting is not currently directly supported between properties within a Collaboration. In our models, a common case where this occurs is where we want to include but Classes and Sub Classes of that class into a Collaboration. Often with additional Connections. It is possible to recursively reference a Collaboration as a CollaborationUse to solve this problem, but that seems somewhat awkward. The Generalization relationship would be a natural addition to the Collaboration Model to represent this. For now, Issue 1 is the primary show-stopper. Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, March 13, 2010 8:03 AM To: Bran Selic Cc: bran.selic@gmail.com; Ericson, George; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran To: Cc: bran.selic@gmail.com, selic@acm.org, uml2-rtf@omg.org Subject: Re: Issue 13452 X-KeepSent: CFA63FB7:179116FB-852576E9:0052B515; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Wed, 17 Mar 2010 11:09:00 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 03/17/2010 12:09:01, Serialize complete at 03/17/2010 12:09:01 Yes, that would violate that constraint. But other standards are also free to extend UML semantics. SoaML provides a profile and MOF metamodel and extends UML with the isStrict property on collaborations. Any inconsistencies are intended to be addressed by the task force, AB and BOD for standards. The clause in 18.1.2 applies to user profiles, not new standards. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/16/2010 09:03 PM Subject: Re: Issue 13452 -------------------------------------------------------------------------------- The reason this makes me uncomfortable is that we define extension to require conformance to the extended element. The definition you are using implies that conformance is not a requirement. Isn't this at odds with clause 18.1.2 Extensibility that asserts: "It is not possible to take away any constraints that apply to a metamodel such as UML using a profile..." [gme: and thus a stereotype] George -------------------------------------------------------------------------------- From: Jim Amsden To: Ericson, George Cc: bran.selic@gmail.com ; Ericson, George; selic@acm.org ; uml2-rtf@omg.org Sent: Tue Mar 16 15:20:12 2010 Subject: RE: Issue 13452 SoaML extends UML and is free to define whatever semantics it requires - as is any other specification. The isStrict property provides additional flexibility in UML models. If isStrict is true, then the normal UML semantics apply. If it is false, then the SoaML extension applies and the collaboration use role bindings don't need to be complete or type compatible. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS, Cc: , Date: 03/16/2010 05:01 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- I thought about applying the same idea as used by SoaML isStrict to a CollaborationUse stereotype as a means to extend the UML model to cover our case. We could add an isMerge attribute to a stereotype that extends CollaborationUse. However, I am concerned that this approach is not consistent with the UML model, since it seems to violate the UML CollaborationUse constraint: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the classifier or operation. (Similarly, I think the SoaML isStrict attribute of a CollaborationUse stereotype violates the UML model type constraint.) I would appreciate guidance on this topic. Thanks, George From: Ericson, George Sent: Saturday, March 13, 2010 9:54 PM To: Jim Amsden; Bran Selic Cc: bran.selic@gmail.com; uml2-rtf@omg.org Subject: RE: Issue 13452 Jim, Bran, Let me back up and explain the use case Iâm trying to solve. We have a Model that includes some 1000 Classes and 600 AssociationClasses. Note, this model currently does not use any simple Associations. The AssociationClasses own their AssociationEnds. For various uses, we want to select some number of Classes and related AssociationClasses and specify implementation requirements. The UML Collaboration seems most amenable to this, but we have some issues. Each of these Collaborations then represents a pattern, or assembly, specification that an implementation must conform to if it claims support for the use represented by the Collaboration. The implementation can be modeled as a Component. In general, there will be a top level Collaboration that an implementation of a Component conforms to. That top level Collaboration is often built up from one or more sub Collaborations. We want to use this modeling technique to SNIAâs SMI-S profiles and DMTFâs Server Management profiles. So, the sub collaborations will often be nested 3-5 layers deep. In other words, these get very complex. Our problem is that we want to keep the presentation and representation as simple as possible. We are looking to do the following: · Collaborations represent a sub model together with implementation requirements and constraints. These are additive to the requirements of the schema. · Classes in our model are represented by Properties of a Collaboration, with specific requirements and constraints on the methods and properties and cardinality of instances of the Class added to the Collaboration Property. · AssociationClasses are represented by Connections of a Collaboration, with specific requirements and constraints on the methods and properties and multiplicities of the AssociationClass added to the Collaboration Connection. · Sub Collaborations are represented by CollaborationUses. Several problems with this approach have been pointed out: 1) We read the constraint mentioned in the issue 13452 would require that each Collaboration explicitly create Properties to represent every Property of all sub Collaborations, represented by CollaborationUses. This is recursive and while we understand that all of these Properties donât need to be shown in related CompositeStructure diagrams, never-the-less it means that the model contains a large number of Properties that could be implied. While the semantics are slightly different, this is very similar to the same problem solved by PackageMerge that implies the existence of the incorporated Elements, without requiring them all to be modeled in the incorporating Package. a. Where we explicitly create a RoleBinding between a Property and a corresponding Property in a CollaborationUse, we expect that the behaviors, requirements, and constraints on the Property create a subset of the Property in the CollaborationUse. b. Where we explicitly do not create RoleBindings to a Property of a CollaborationUse, we expect that the behaviors, requirements and constraints of that Property are incorporated into the Collaboration that specifies the CollaborationUse. It would be ideal if this is already what you intend for the semantics of CollaborationUse. If not, perhaps a boolean attribute could be added to the CollaborationUse that specifies this behavior. 2) We read the model for Connector to allow the type to be an AssociationClass, but this is somewhat controversial and not well-supported by the UML tool industry. 3) We read RoleBinding as an alternative representation of Subset relationship between properties. However, subsetting is not currently directly supported between properties within a Collaboration. In our models, a common case where this occurs is where we want to include but Classes and Sub Classes of that class into a Collaboration. Often with additional Connections. It is possible to recursively reference a Collaboration as a CollaborationUse to solve this problem, but that seems somewhat awkward. The Generalization relationship would be a natural addition to the Collaboration Model to represent this. For now, Issue 1 is the primary show-stopper. Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, March 13, 2010 8:03 AM To: Bran Selic Cc: bran.selic@gmail.com; Ericson, George; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran To: Cc: bran.selic@gmail.com, selic@acm.org, uml2-rtf@omg.org Subject: RE: Issue 13452 X-KeepSent: 67E3F3C8:0F885578-852576E9:00634DD0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Wed, 17 Mar 2010 14:18:31 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 03/17/2010 15:18:34, Serialize complete at 03/17/2010 15:18:34 George, Let's look specifically at the issue: "Assuming one Collaboration represents mandatory features and another Collaboration wants to extend that. It seems natural to express only the differences in the second Collaboration and to use roleBinding to between properties of the extending Collaboration to properties of a CollaborationUse of the first. The implication is that properties of the first collaboration are included as part of the second collaboration, since the CollaborationUse is essentially an instantiation of the first Collaboration in the context of the second. The roleBindings indicate were instances of the properties of first are constrained to be instances of the second Collaboration. This usage would require that the 2nd constraint be modified and that properties of the CollaborationUse of the first Collaboration are interpreted as being incorporated into the second Collaboration except when there is a roleBinding between the properties of the first and second Collaborations. " A Collaboration represents a pattern of interaction between roles (structurally with connectors between the parts/roles of the collaboration and behaviorally using owned behaviors of the collaboration). A Collaboration is a generalizable element, so it can have specializations that add additional roles, connections and behaviors, including redefinitions. A CollaborationUse is a typed element that is essentially an "instance" of a Collaboration. It shows that the containing element (usually a classifier of some sort) adheres to the pattern of interaction described by the interaction. The CollaborationUse role bindings indicate what part of the owner of the collaboration use plays what role in the defining collaboration. So you would expect a specialization of a collaboration to include all its roles and the inherited roles, and a CollaborationUse typed by such a collaboration would need to have role bindings to parts for every one of those roles. I wouldn't expect to see a CollaborationUse for both the general and specific Collaborations in the same context as that would be redundant. If on the other hand, you had a superclass that adhered to a collaboration, you could have a subclass that adheres to the specialized collaboration. Currently there's no way to separate the collaboration use into two parts - just like there's no way to separate an instance of a class into parts representing its superclasses. The same collaboration use couldn't appear in two different classifiers. So I think the resolution to this issue is to specialize the collaboration, and use a collaboration use of the specialized collaboration with all role bindings in one place. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/17/2010 04:56 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- So do you recommend: A) DMTF create a version of a UML Profile for CIM that solves the 13452 issue? a. If so, is it sufficient for this to be a DMTF standard, or must it be an OMG standard? B) OMG extend UML to support merge semantics for Properties of a CollaborationUse? Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, March 17, 2010 11:09 AM To: Ericson, George Cc: bran.selic@gmail.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: Issue 13452 Yes, that would violate that constraint. But other standards are also free to extend UML semantics. SoaML provides a profile and MOF metamodel and extends UML with the isStrict property on collaborations. Any inconsistencies are intended to be addressed by the task force, AB and BOD for standards. The clause in 18.1.2 applies to user profiles, not new standards. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/16/2010 09:03 PM Subject: Re: Issue 13452 -------------------------------------------------------------------------------- The reason this makes me uncomfortable is that we define extension to require conformance to the extended element. The definition you are using implies that conformance is not a requirement. Isn't this at odds with clause 18.1.2 Extensibility that asserts: "It is not possible to take away any constraints that apply to a metamodel such as UML using a profile..." [gme: and thus a stereotype] George -------------------------------------------------------------------------------- From: Jim Amsden To: Ericson, George Cc: bran.selic@gmail.com ; Ericson, George; selic@acm.org ; uml2-rtf@omg.org Sent: Tue Mar 16 15:20:12 2010 Subject: RE: Issue 13452 SoaML extends UML and is free to define whatever semantics it requires - as is any other specification. The isStrict property provides additional flexibility in UML models. If isStrict is true, then the normal UML semantics apply. If it is false, then the SoaML extension applies and the collaboration use role bindings don't need to be complete or type compatible. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS, Cc: , Date: 03/16/2010 05:01 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- I thought about applying the same idea as used by SoaML isStrict to a CollaborationUse stereotype as a means to extend the UML model to cover our case. We could add an isMerge attribute to a stereotype that extends CollaborationUse. However, I am concerned that this approach is not consistent with the UML model, since it seems to violate the UML CollaborationUse constraint: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the classifier or operation. (Similarly, I think the SoaML isStrict attribute of a CollaborationUse stereotype violates the UML model type constraint.) I would appreciate guidance on this topic. Thanks, George From: Ericson, George Sent: Saturday, March 13, 2010 9:54 PM To: Jim Amsden; Bran Selic Cc: bran.selic@gmail.com; uml2-rtf@omg.org Subject: RE: Issue 13452 Jim, Bran, Let me back up and explain the use case Iâm trying to solve. We have a Model that includes some 1000 Classes and 600 AssociationClasses. Note, this model currently does not use any simple Associations. The AssociationClasses own their AssociationEnds. For various uses, we want to select some number of Classes and related AssociationClasses and specify implementation requirements. The UML Collaboration seems most amenable to this, but we have some issues. Each of these Collaborations then represents a pattern, or assembly, specification that an implementation must conform to if it claims support for the use represented by the Collaboration. The implementation can be modeled as a Component. In general, there will be a top level Collaboration that an implementation of a Component conforms to. That top level Collaboration is often built up from one or more sub Collaborations. We want to use this modeling technique to SNIAâs SMI-S profiles and DMTFâs Server Management profiles. So, the sub collaborations will often be nested 3-5 layers deep. In other words, these get very complex. Our problem is that we want to keep the presentation and representation as simple as possible. We are looking to do the following: · Collaborations represent a sub model together with implementation requirements and constraints. These are additive to the requirements of the schema. · Classes in our model are represented by Properties of a Collaboration, with specific requirements and constraints on the methods and properties and cardinality of instances of the Class added to the Collaboration Property. · AssociationClasses are represented by Connections of a Collaboration, with specific requirements and constraints on the methods and properties and multiplicities of the AssociationClass added to the Collaboration Connection. · Sub Collaborations are represented by CollaborationUses. Several problems with this approach have been pointed out: 1) We read the constraint mentioned in the issue 13452 would require that each Collaboration explicitly create Properties to represent every Property of all sub Collaborations, represented by CollaborationUses. This is recursive and while we understand that all of these Properties donât need to be shown in related CompositeStructure diagrams, never-the-less it means that the model contains a large number of Properties that could be implied. While the semantics are slightly different, this is very similar to the same problem solved by PackageMerge that implies the existence of the incorporated Elements, without requiring them all to be modeled in the incorporating Package. a. Where we explicitly create a RoleBinding between a Property and a corresponding Property in a CollaborationUse, we expect that the behaviors, requirements, and constraints on the Property create a subset of the Property in the CollaborationUse. b. Where we explicitly do not create RoleBindings to a Property of a CollaborationUse, we expect that the behaviors, requirements and constraints of that Property are incorporated into the Collaboration that specifies the CollaborationUse. It would be ideal if this is already what you intend for the semantics of CollaborationUse. If not, perhaps a boolean attribute could be added to the CollaborationUse that specifies this behavior. 2) We read the model for Connector to allow the type to be an AssociationClass, but this is somewhat controversial and not well-supported by the UML tool industry. 3) We read RoleBinding as an alternative representation of Subset relationship between properties. However, subsetting is not currently directly supported between properties within a Collaboration. In our models, a common case where this occurs is where we want to include but Classes and Sub Classes of that class into a Collaboration. Often with additional Connections. It is possible to recursively reference a Collaboration as a CollaborationUse to solve this problem, but that seems somewhat awkward. The Generalization relationship would be a natural addition to the Collaboration Model to represent this. For now, Issue 1 is the primary show-stopper. Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, March 13, 2010 8:03 AM To: Bran Selic Cc: bran.selic@gmail.com; Ericson, George; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran From: Steve Cook To: Jim Amsden , "ericson_george@emc.com" CC: "bran.selic@gmail.com" , "selic@acm.org" , "uml2-rtf@omg.org" Subject: RE: Issue 13452 Thread-Topic: Issue 13452 Thread-Index: AcrFVumRl73lSH8JQ7KyqW+cJ+Sf+AAFjai7AB2pZQAACAORcA== Date: Wed, 17 Mar 2010 19:01:26 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Jim, when you say .inconsistencies are intended to be addressed by the task force, AB and BOD., are you saying that issue 13452 needs to be resolved in order for SoaML to be consistent with UML? Or are you saying that there is another issue that needs to be resolved for SoaML to be consistent with UML, and if so has that issue been logged? Thanks -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 17 March 2010 15:09 To: ericson_george@emc.com Cc: bran.selic@gmail.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: Issue 13452 Yes, that would violate that constraint. But other standards are also free to extend UML semantics. SoaML provides a profile and MOF metamodel and extends UML with the isStrict property on collaborations. Any inconsistencies are intended to be addressed by the task force, AB and BOD for standards. The clause in 18.1.2 applies to user profiles, not new standards. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/16/2010 09:03 PM Subject: Re: Issue 13452 -------------------------------------------------------------------------------- The reason this makes me uncomfortable is that we define extension to require conformance to the extended element. The definition you are using implies that conformance is not a requirement. Isn't this at odds with clause 18.1.2 Extensibility that asserts: "It is not possible to take away any constraints that apply to a metamodel such as UML using a profile..." [gme: and thus a stereotype] George -------------------------------------------------------------------------------- From: Jim Amsden To: Ericson, George Cc: bran.selic@gmail.com ; Ericson, George; selic@acm.org ; uml2-rtf@omg.org Sent: Tue Mar 16 15:20:12 2010 Subject: RE: Issue 13452 SoaML extends UML and is free to define whatever semantics it requires - as is any other specification. The isStrict property provides additional flexibility in UML models. If isStrict is true, then the normal UML semantics apply. If it is false, then the SoaML extension applies and the collaboration use role bindings don't need to be complete or type compatible. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS, Cc: , Date: 03/16/2010 05:01 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- I thought about applying the same idea as used by SoaML isStrict to a CollaborationUse stereotype as a means to extend the UML model to cover our case. We could add an isMerge attribute to a stereotype that extends CollaborationUse. However, I am concerned that this approach is not consistent with the UML model, since it seems to violate the UML CollaborationUse constraint: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the classifier or operation. (Similarly, I think the SoaML isStrict attribute of a CollaborationUse stereotype violates the UML model type constraint.) I would appreciate guidance on this topic. Thanks, George From: Ericson, George Sent: Saturday, March 13, 2010 9:54 PM To: Jim Amsden; Bran Selic Cc: bran.selic@gmail.com; uml2-rtf@omg.org Subject: RE: Issue 13452 Jim, Bran, Let me back up and explain the use case I.m trying to solve. We have a Model that includes some 1000 Classes and 600 AssociationClasses. Note, this model currently does not use any simple Associations. The AssociationClasses own their AssociationEnds. For various uses, we want to select some number of Classes and related AssociationClasses and specify implementation requirements. The UML Collaboration seems most amenable to this, but we have some issues. Each of these Collaborations then represents a pattern, or assembly, specification that an implementation must conform to if it claims support for the use represented by the Collaboration. The implementation can be modeled as a Component. In general, there will be a top level Collaboration that an implementation of a Component conforms to. That top level Collaboration is often built up from one or more sub Collaborations. We want to use this modeling technique to SNIA.s SMI-S profiles and DMTF.s Server Management profiles. So, the sub collaborations will often be nested 3-5 layers deep. In other words, these get very complex. Our problem is that we want to keep the presentation and representation as simple as possible. We are looking to do the following: · Collaborations represent a sub model together with implementation requirements and constraints. These are additive to the requirements of the schema. · Classes in our model are represented by Properties of a Collaboration, with specific requirements and constraints on the methods and properties and cardinality of instances of the Class added to the Collaboration Property. · AssociationClasses are represented by Connections of a Collaboration, with specific requirements and constraints on the methods and properties and multiplicities of the AssociationClass added to the Collaboration Connection. · Sub Collaborations are represented by CollaborationUses. Several problems with this approach have been pointed out: 1) We read the constraint mentioned in the issue 13452 would require that each Collaboration explicitly create Properties to represent every Property of all sub Collaborations, represented by CollaborationUses. This is recursive and while we understand that all of these Properties don.t need to be shown in related CompositeStructure diagrams, never-the-less it means that the model contains a large number of Properties that could be implied. While the semantics are slightly different, this is very similar to the same problem solved by PackageMerge that implies the existence of the incorporated Elements, without requiring them all to be modeled in the incorporating Package. a. Where we explicitly create a RoleBinding between a Property and a corresponding Property in a CollaborationUse, we expect that the behaviors, requirements, and constraints on the Property create a subset of the Property in the CollaborationUse. b. Where we explicitly do not create RoleBindings to a Property of a CollaborationUse, we expect that the behaviors, requirements and constraints of that Property are incorporated into the Collaboration that specifies the CollaborationUse. It would be ideal if this is already what you intend for the semantics of CollaborationUse. If not, perhaps a boolean attribute could be added to the CollaborationUse that specifies this behavior. 2) We read the model for Connector to allow the type to be an AssociationClass, but this is somewhat controversial and not well-supported by the UML tool industry. 3) We read RoleBinding as an alternative representation of Subset relationship between properties. However, subsetting is not currently directly supported between properties within a Collaboration. In our models, a common case where this occurs is where we want to include but Classes and Sub Classes of that class into a Collaboration. Often with additional Connections. It is possible to recursively reference a Collaboration as a CollaborationUse to solve this problem, but that seems somewhat awkward. The Generalization relationship would be a natural addition to the Collaboration Model to represent this. For now, Issue 1 is the primary show-stopper. Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, March 13, 2010 8:03 AM To: Bran Selic Cc: bran.selic@gmail.com; Ericson, George; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran Subject: RE: Issue 13452 Date: Wed, 17 Mar 2010 16:51:03 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 13452 Thread-Index: AcrF/QGrB/vi7ro1RkCmPqScdWXTfQAFcknA From: To: Cc: , , X-OriginalArrivalTime: 17 Mar 2010 20:51:04.0156 (UTC) FILETIME=[8F2279C0:01CAC613] X-EMM-EM: Active So do you recommend: A) DMTF create a version of a UML Profile for CIM that solves the 13452 issue? a. If so, is it sufficient for this to be a DMTF standard, or must it be an OMG standard? B) OMG extend UML to support merge semantics for Properties of a CollaborationUse? Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, March 17, 2010 11:09 AM To: Ericson, George Cc: bran.selic@gmail.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: Issue 13452 Yes, that would violate that constraint. But other standards are also free to extend UML semantics. SoaML provides a profile and MOF metamodel and extends UML with the isStrict property on collaborations. Any inconsistencies are intended to be addressed by the task force, AB and BOD for standards. The clause in 18.1.2 applies to user profiles, not new standards. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/16/2010 09:03 PM Subject: Re: Issue 13452 -------------------------------------------------------------------------------- The reason this makes me uncomfortable is that we define extension to require conformance to the extended element. The definition you are using implies that conformance is not a requirement. Isn't this at odds with clause 18.1.2 Extensibility that asserts: "It is not possible to take away any constraints that apply to a metamodel such as UML using a profile..." [gme: and thus a stereotype] George -------------------------------------------------------------------------------- From: Jim Amsden To: Ericson, George Cc: bran.selic@gmail.com ; Ericson, George; selic@acm.org ; uml2-rtf@omg.org Sent: Tue Mar 16 15:20:12 2010 Subject: RE: Issue 13452 SoaML extends UML and is free to define whatever semantics it requires - as is any other specification. The isStrict property provides additional flexibility in UML models. If isStrict is true, then the normal UML semantics apply. If it is false, then the SoaML extension applies and the collaboration use role bindings don't need to be complete or type compatible. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS, Cc: , Date: 03/16/2010 05:01 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- I thought about applying the same idea as used by SoaML isStrict to a CollaborationUse stereotype as a means to extend the UML model to cover our case. We could add an isMerge attribute to a stereotype that extends CollaborationUse. However, I am concerned that this approach is not consistent with the UML model, since it seems to violate the UML CollaborationUse constraint: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the classifier or operation. (Similarly, I think the SoaML isStrict attribute of a CollaborationUse stereotype violates the UML model type constraint.) I would appreciate guidance on this topic. Thanks, George From: Ericson, George Sent: Saturday, March 13, 2010 9:54 PM To: Jim Amsden; Bran Selic Cc: bran.selic@gmail.com; uml2-rtf@omg.org Subject: RE: Issue 13452 Jim, Bran, Let me back up and explain the use case I.m trying to solve. We have a Model that includes some 1000 Classes and 600 AssociationClasses. Note, this model currently does not use any simple Associations. The AssociationClasses own their AssociationEnds. For various uses, we want to select some number of Classes and related AssociationClasses and specify implementation requirements. The UML Collaboration seems most amenable to this, but we have some issues. Each of these Collaborations then represents a pattern, or assembly, specification that an implementation must conform to if it claims support for the use represented by the Collaboration. The implementation can be modeled as a Component. In general, there will be a top level Collaboration that an implementation of a Component conforms to. That top level Collaboration is often built up from one or more sub Collaborations. We want to use this modeling technique to SNIA.s SMI-S profiles and DMTF.s Server Management profiles. So, the sub collaborations will often be nested 3-5 layers deep. In other words, these get very complex. Our problem is that we want to keep the presentation and representation as simple as possible. We are looking to do the following: · Collaborations represent a sub model together with implementation requirements and constraints. These are additive to the requirements of the schema. · Classes in our model are represented by Properties of a Collaboration, with specific requirements and constraints on the methods and properties and cardinality of instances of the Class added to the Collaboration Property. · AssociationClasses are represented by Connections of a Collaboration, with specific requirements and constraints on the methods and properties and multiplicities of the AssociationClass added to the Collaboration Connection. · Sub Collaborations are represented by CollaborationUses. Several problems with this approach have been pointed out: 1) We read the constraint mentioned in the issue 13452 would require that each Collaboration explicitly create Properties to represent every Property of all sub Collaborations, represented by CollaborationUses. This is recursive and while we understand that all of these Properties don.t need to be shown in related CompositeStructure diagrams, never-the-less it means that the model contains a large number of Properties that could be implied. While the semantics are slightly different, this is very similar to the same problem solved by PackageMerge that implies the existence of the incorporated Elements, without requiring them all to be modeled in the incorporating Package. a. Where we explicitly create a RoleBinding between a Property and a corresponding Property in a CollaborationUse, we expect that the behaviors, requirements, and constraints on the Property create a subset of the Property in the CollaborationUse. b. Where we explicitly do not create RoleBindings to a Property of a CollaborationUse, we expect that the behaviors, requirements and constraints of that Property are incorporated into the Collaboration that specifies the CollaborationUse. It would be ideal if this is already what you intend for the semantics of CollaborationUse. If not, perhaps a boolean attribute could be added to the CollaborationUse that specifies this behavior. 2) We read the model for Connector to allow the type to be an AssociationClass, but this is somewhat controversial and not well-supported by the UML tool industry. 3) We read RoleBinding as an alternative representation of Subset relationship between properties. However, subsetting is not currently directly supported between properties within a Collaboration. In our models, a common case where this occurs is where we want to include but Classes and Sub Classes of that class into a Collaboration. Often with additional Connections. It is possible to recursively reference a Collaboration as a CollaborationUse to solve this problem, but that seems somewhat awkward. The Generalization relationship would be a natural addition to the Collaboration Model to represent this. For now, Issue 1 is the primary show-stopper. Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, March 13, 2010 8:03 AM To: Bran Selic Cc: bran.selic@gmail.com; Ericson, George; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran Subject: RE: Issue 13452 Date: Wed, 17 Mar 2010 17:08:23 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 13452 Thread-Index: AcrFVumRl73lSH8JQ7KyqW+cJ+Sf+AAFjai7AB2pZQAACAORcAAEOxdw From: To: , Cc: , , X-OriginalArrivalTime: 17 Mar 2010 21:08:25.0003 (UTC) FILETIME=[FB871FB0:01CAC615] X-EMM-EM: Active 13452 is independent of SoaML. 13452 asks that a capability like PackageMerge be available to relate a CollaborationUse to a Collaboration, with the implication that all Properties and Connections of the CollaborationUse that are not explicitly named in RoleBindings are imported as Properties and Connections the Collaboration. The open question is whether this can be implemented via a Stereotype, (as was done for a different issue in SoaML), or must UML itself be extended. As I understand Jim, this comes down to whether or not our profile (UML Profile for CIM) is a standard or not. If so, I.m not clear on whether it needs to be an OMG standard or not. George From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Wednesday, March 17, 2010 3:01 PM To: Jim Amsden; Ericson, George Cc: bran.selic@gmail.com; selic@acm.org; uml2-rtf@omg.org Subject: RE: Issue 13452 Jim, when you say .inconsistencies are intended to be addressed by the task force, AB and BOD., are you saying that issue 13452 needs to be resolved in order for SoaML to be consistent with UML? Or are you saying that there is another issue that needs to be resolved for SoaML to be consistent with UML, and if so has that issue been logged? Thanks -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 17 March 2010 15:09 To: ericson_george@emc.com Cc: bran.selic@gmail.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: Issue 13452 Yes, that would violate that constraint. But other standards are also free to extend UML semantics. SoaML provides a profile and MOF metamodel and extends UML with the isStrict property on collaborations. Any inconsistencies are intended to be addressed by the task force, AB and BOD for standards. The clause in 18.1.2 applies to user profiles, not new standards. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/16/2010 09:03 PM Subject: Re: Issue 13452 -------------------------------------------------------------------------------- The reason this makes me uncomfortable is that we define extension to require conformance to the extended element. The definition you are using implies that conformance is not a requirement. Isn't this at odds with clause 18.1.2 Extensibility that asserts: "It is not possible to take away any constraints that apply to a metamodel such as UML using a profile..." [gme: and thus a stereotype] George -------------------------------------------------------------------------------- From: Jim Amsden To: Ericson, George Cc: bran.selic@gmail.com ; Ericson, George; selic@acm.org ; uml2-rtf@omg.org Sent: Tue Mar 16 15:20:12 2010 Subject: RE: Issue 13452 SoaML extends UML and is free to define whatever semantics it requires - as is any other specification. The isStrict property provides additional flexibility in UML models. If isStrict is true, then the normal UML semantics apply. If it is false, then the SoaML extension applies and the collaboration use role bindings don't need to be complete or type compatible. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS, Cc: , Date: 03/16/2010 05:01 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- I thought about applying the same idea as used by SoaML isStrict to a CollaborationUse stereotype as a means to extend the UML model to cover our case. We could add an isMerge attribute to a stereotype that extends CollaborationUse. However, I am concerned that this approach is not consistent with the UML model, since it seems to violate the UML CollaborationUse constraint: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the classifier or operation. (Similarly, I think the SoaML isStrict attribute of a CollaborationUse stereotype violates the UML model type constraint.) I would appreciate guidance on this topic. Thanks, George From: Ericson, George Sent: Saturday, March 13, 2010 9:54 PM To: Jim Amsden; Bran Selic Cc: bran.selic@gmail.com; uml2-rtf@omg.org Subject: RE: Issue 13452 Jim, Bran, Let me back up and explain the use case I.m trying to solve. We have a Model that includes some 1000 Classes and 600 AssociationClasses. Note, this model currently does not use any simple Associations. The AssociationClasses own their AssociationEnds. For various uses, we want to select some number of Classes and related AssociationClasses and specify implementation requirements. The UML Collaboration seems most amenable to this, but we have some issues. Each of these Collaborations then represents a pattern, or assembly, specification that an implementation must conform to if it claims support for the use represented by the Collaboration. The implementation can be modeled as a Component. In general, there will be a top level Collaboration that an implementation of a Component conforms to. That top level Collaboration is often built up from one or more sub Collaborations. We want to use this modeling technique to SNIA.s SMI-S profiles and DMTF.s Server Management profiles. So, the sub collaborations will often be nested 3-5 layers deep. In other words, these get very complex. Our problem is that we want to keep the presentation and representation as simple as possible. We are looking to do the following: · Collaborations represent a sub model together with implementation requirements and constraints. These are additive to the requirements of the schema. · Classes in our model are represented by Properties of a Collaboration, with specific requirements and constraints on the methods and properties and cardinality of instances of the Class added to the Collaboration Property. · AssociationClasses are represented by Connections of a Collaboration, with specific requirements and constraints on the methods and properties and multiplicities of the AssociationClass added to the Collaboration Connection. · Sub Collaborations are represented by CollaborationUses. Several problems with this approach have been pointed out: 1) We read the constraint mentioned in the issue 13452 would require that each Collaboration explicitly create Properties to represent every Property of all sub Collaborations, represented by CollaborationUses. This is recursive and while we understand that all of these Properties don.t need to be shown in related CompositeStructure diagrams, never-the-less it means that the model contains a large number of Properties that could be implied. While the semantics are slightly different, this is very similar to the same problem solved by PackageMerge that implies the existence of the incorporated Elements, without requiring them all to be modeled in the incorporating Package. a. Where we explicitly create a RoleBinding between a Property and a corresponding Property in a CollaborationUse, we expect that the behaviors, requirements, and constraints on the Property create a subset of the Property in the CollaborationUse. b. Where we explicitly do not create RoleBindings to a Property of a CollaborationUse, we expect that the behaviors, requirements and constraints of that Property are incorporated into the Collaboration that specifies the CollaborationUse. It would be ideal if this is already what you intend for the semantics of CollaborationUse. If not, perhaps a boolean attribute could be added to the CollaborationUse that specifies this behavior. 2) We read the model for Connector to allow the type to be an AssociationClass, but this is somewhat controversial and not well-supported by the UML tool industry. 3) We read RoleBinding as an alternative representation of Subset relationship between properties. However, subsetting is not currently directly supported between properties within a Collaboration. In our models, a common case where this occurs is where we want to include but Classes and Sub Classes of that class into a Collaboration. Often with additional Connections. It is possible to recursively reference a Collaboration as a CollaborationUse to solve this problem, but that seems somewhat awkward. The Generalization relationship would be a natural addition to the Collaboration Model to represent this. For now, Issue 1 is the primary show-stopper. Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, March 13, 2010 8:03 AM To: Bran Selic Cc: bran.selic@gmail.com; Ericson, George; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran Subject: RE: Issue 13452 Date: Wed, 17 Mar 2010 22:04:44 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Issue 13452 Thread-Index: AcrGF36tTFF50JTNTBOWmbh9ERvspQABiYkw From: To: Cc: , , X-OriginalArrivalTime: 18 Mar 2010 02:09:09.0927 (UTC) FILETIME=[FF240370:01CAC63F] X-EMM-EM: Active This is an interesting idea. I tried it out with three Collaborations with a UML tool that I think does a pretty good job of following the UML specification: Collaboration: Base Collaboration: Extend (condensed view) Collaboration: Extend (expanded view) Collaboration: SubExtend These results are not quite what I expect. The expected result would be: So, at least for this tool, your suggestion doesn.t produce the desired results. My questions are: 1) Did the tool follow the specification correctly? a. I think there are some issues. i. Dropped and Extra Role Bindings and dropped Connections in expanded view ii. Property A carried into Extend and SubExtend. My expectation was that only the subsets named by E and D should be present. iii. Dropped Role Bindings, CollaborationUse and Connections in subExtend Collaboration. 2) What needs to change to reach the expected result? Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, March 17, 2010 2:19 PM To: Ericson, George Cc: bran.selic@gmail.com; selic@acm.org; uml2-rtf@omg.org Subject: RE: Issue 13452 George, Let's look specifically at the issue: "Assuming one Collaboration represents mandatory features and another Collaboration wants to extend that. It seems natural to express only the differences in the second Collaboration and to use roleBinding to between properties of the extending Collaboration to properties of a CollaborationUse of the first. The implication is that properties of the first collaboration are included as part of the second collaboration, since the CollaborationUse is essentially an instantiation of the first Collaboration in the context of the second. The roleBindings indicate were instances of the properties of first are constrained to be instances of the second Collaboration. This usage would require that the 2nd constraint be modified and that properties of the CollaborationUse of the first Collaboration are interpreted as being incorporated into the second Collaboration except when there is a roleBinding between the properties of the first and second Collaborations. " A Collaboration represents a pattern of interaction between roles (structurally with connectors between the parts/roles of the collaboration and behaviorally using owned behaviors of the collaboration). A Collaboration is a generalizable element, so it can have specializations that add additional roles, connections and behaviors, including redefinitions. A CollaborationUse is a typed element that is essentially an "instance" of a Collaboration. It shows that the containing element (usually a classifier of some sort) adheres to the pattern of interaction described by the interaction. The CollaborationUse role bindings indicate what part of the owner of the collaboration use plays what role in the defining collaboration. So you would expect a specialization of a collaboration to include all its roles and the inherited roles, and a CollaborationUse typed by such a collaboration would need to have role bindings to parts for every one of those roles. I wouldn't expect to see a CollaborationUse for both the general and specific Collaborations in the same context as that would be redundant. If on the other hand, you had a superclass that adhered to a collaboration, you could have a subclass that adheres to the specialized collaboration. Currently there's no way to separate the collaboration use into two parts - just like there's no way to separate an instance of a class into parts representing its superclasses. The same collaboration use couldn't appear in two different classifiers. So I think the resolution to this issue is to specialize the collaboration, and use a collaboration use of the specialized collaboration with all role bindings in one place. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/17/2010 04:56 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- So do you recommend: A) DMTF create a version of a UML Profile for CIM that solves the 13452 issue? a. If so, is it sufficient for this to be a DMTF standard, or must it be an OMG standard? B) OMG extend UML to support merge semantics for Properties of a CollaborationUse? Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, March 17, 2010 11:09 AM To: Ericson, George Cc: bran.selic@gmail.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: Issue 13452 Yes, that would violate that constraint. But other standards are also free to extend UML semantics. SoaML provides a profile and MOF metamodel and extends UML with the isStrict property on collaborations. Any inconsistencies are intended to be addressed by the task force, AB and BOD for standards. The clause in 18.1.2 applies to user profiles, not new standards. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/16/2010 09:03 PM Subject: Re: Issue 13452 -------------------------------------------------------------------------------- The reason this makes me uncomfortable is that we define extension to require conformance to the extended element. The definition you are using implies that conformance is not a requirement. Isn't this at odds with clause 18.1.2 Extensibility that asserts: "It is not possible to take away any constraints that apply to a metamodel such as UML using a profile..." [gme: and thus a stereotype] George -------------------------------------------------------------------------------- From: Jim Amsden To: Ericson, George Cc: bran.selic@gmail.com ; Ericson, George; selic@acm.org ; uml2-rtf@omg.org Sent: Tue Mar 16 15:20:12 2010 Subject: RE: Issue 13452 SoaML extends UML and is free to define whatever semantics it requires - as is any other specification. The isStrict property provides additional flexibility in UML models. If isStrict is true, then the normal UML semantics apply. If it is false, then the SoaML extension applies and the collaboration use role bindings don't need to be complete or type compatible. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS, Cc: , Date: 03/16/2010 05:01 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- I thought about applying the same idea as used by SoaML isStrict to a CollaborationUse stereotype as a means to extend the UML model to cover our case. We could add an isMerge attribute to a stereotype that extends CollaborationUse. However, I am concerned that this approach is not consistent with the UML model, since it seems to violate the UML CollaborationUse constraint: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the classifier or operation. (Similarly, I think the SoaML isStrict attribute of a CollaborationUse stereotype violates the UML model type constraint.) I would appreciate guidance on this topic. Thanks, George From: Ericson, George Sent: Saturday, March 13, 2010 9:54 PM To: Jim Amsden; Bran Selic Cc: bran.selic@gmail.com; uml2-rtf@omg.org Subject: RE: Issue 13452 Jim, Bran, Let me back up and explain the use case I.m trying to solve. We have a Model that includes some 1000 Classes and 600 AssociationClasses. Note, this model currently does not use any simple Associations. The AssociationClasses own their AssociationEnds. For various uses, we want to select some number of Classes and related AssociationClasses and specify implementation requirements. The UML Collaboration seems most amenable to this, but we have some issues. Each of these Collaborations then represents a pattern, or assembly, specification that an implementation must conform to if it claims support for the use represented by the Collaboration. The implementation can be modeled as a Component. In general, there will be a top level Collaboration that an implementation of a Component conforms to. That top level Collaboration is often built up from one or more sub Collaborations. We want to use this modeling technique to SNIA.s SMI-S profiles and DMTF.s Server Management profiles. So, the sub collaborations will often be nested 3-5 layers deep. In other words, these get very complex. Our problem is that we want to keep the presentation and representation as simple as possible. We are looking to do the following: · Collaborations represent a sub model together with implementation requirements and constraints. These are additive to the requirements of the schema. · Classes in our model are represented by Properties of a Collaboration, with specific requirements and constraints on the methods and properties and cardinality of instances of the Class added to the Collaboration Property. · AssociationClasses are represented by Connections of a Collaboration, with specific requirements and constraints on the methods and properties and multiplicities of the AssociationClass added to the Collaboration Connection. · Sub Collaborations are represented by CollaborationUses. Several problems with this approach have been pointed out: 1) We read the constraint mentioned in the issue 13452 would require that each Collaboration explicitly create Properties to represent every Property of all sub Collaborations, represented by CollaborationUses. This is recursive and while we understand that all of these Properties don.t need to be shown in related CompositeStructure diagrams, never-the-less it means that the model contains a large number of Properties that could be implied. While the semantics are slightly different, this is very similar to the same problem solved by PackageMerge that implies the existence of the incorporated Elements, without requiring them all to be modeled in the incorporating Package. a. Where we explicitly create a RoleBinding between a Property and a corresponding Property in a CollaborationUse, we expect that the behaviors, requirements, and constraints on the Property create a subset of the Property in the CollaborationUse. b. Where we explicitly do not create RoleBindings to a Property of a CollaborationUse, we expect that the behaviors, requirements and constraints of that Property are incorporated into the Collaboration that specifies the CollaborationUse. It would be ideal if this is already what you intend for the semantics of CollaborationUse. If not, perhaps a boolean attribute could be added to the CollaborationUse that specifies this behavior. 2) We read the model for Connector to allow the type to be an AssociationClass, but this is somewhat controversial and not well-supported by the UML tool industry. 3) We read RoleBinding as an alternative representation of Subset relationship between properties. However, subsetting is not currently directly supported between properties within a Collaboration. In our models, a common case where this occurs is where we want to include but Classes and Sub Classes of that class into a Collaboration. Often with additional Connections. It is possible to recursively reference a Collaboration as a CollaborationUse to solve this problem, but that seems somewhat awkward. The Generalization relationship would be a natural addition to the Collaboration Model to represent this. For now, Issue 1 is the primary show-stopper. Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, March 13, 2010 8:03 AM To: Bran Selic Cc: bran.selic@gmail.com; Ericson, George; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran To: Cc: bran.selic@gmail.com, selic@acm.org, uml2-rtf@omg.org Subject: RE: Issue 13452 X-KeepSent: 1C9698CC:67BE1D29-852576EB:0001F262; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Thu, 18 Mar 2010 22:29:19 -0600 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 03/18/2010 22:29:24, Serialize complete at 03/18/2010 22:29:24 George, I don't understand the example. Comments embedded below... Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/17/2010 10:13 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- This is an interesting idea. I tried it out with three Collaborations with a UML tool that I think does a pretty good job of following the UML specification: So you have a Collaboration Base which defines some pattern of interaction between its (so far unspecified) roles. This is extended with Collaboration Extension which presumably adds more roles or different interactions. That is in turn specialized somehow with SubExtension. So far, this is an under-specified model since we don't know the roles or what the extensions actually are. Collaboration: Base I'm not exactly sure of the notation being used here, but I assume this is an structure diagram for collaboration Base (instead of showing the roles in the collaboration which would be the usual notation, but this is not incorrect). So we see there are three roles, with A connected to B and B connected to C, but we don't know anything about the roles - their types or the behaviors of collaboration base to indicate how the roles are intended to interact. Again, this is a bit under-specified, so it will be hard to know that the specializations might mean. Collaboration: Extend (condensed view) Now this is strange. You have a collaboration Extension which specializes Base and therefore has roles A, B and C plus their connections. This adds new roles D, E, and F with their connections. The collaboration use :Base makes no sense here. It is binding roles to inherited parts, and the role B is not bound. D and E are bound to role A, which is also part of Extension since they are inherited. Why have Extension inherit from Base and conform partially to the pattern of interactions specified by Base? That seems both incomplete and possibly redundant. Extension already contains A, B and C with their connections, why have additional roles that somehow overlap through the bindings with inherited roles? I suppose this is legal, but it seems pretty contrived and unusual. Can you provide a more realistic example? Collaboration: Extend (expanded view) Yes, but what does this mean? Why do D and E have multiple bindings to A? What plays the B and C role in Extension - inherited B and C? If you remove the collaboration use :Base from the Extension collaboration, then you would be defining a collaboration that specializes another collaboration by adding roles D, E and F. That seems fine. Anything that adheres to collaboration Base would have a collaboration use :Base with role bindings to A, B and C. Anything that adhered to the collaboration Extension would have role bindings for A, B, C, D, E and F. That seems pretty straight forward. Collaboration: SubExtend SubExtension appears identical to Extension given the available information. These results are not quite what I expect. The expected result would be: The tool seems to be inferring that an inherited role is a part that automatically binds to the collaboration use of its general collaboration. Again, this seems to me to have little value, and I have no idea if it is valid UML or not. Certainly the role bindings can be made, and inherited role C would certainly be compatible with the role it is bound to since it is the same thing. But this makes no sense. Perhaps you could provide a more realistic example explaining what you're trying to do? So, at least for this tool, your suggestion doesnât produce the desired results. My questions are: 1) Did the tool follow the specification correctly? a. I think there are some issues. i. Dropped and Extra Role Bindings and dropped Connections in expanded view ii. Property A carried into Extend and SubExtend. My expectation was that only the subsets named by E and D should be present. iii. Dropped Role Bindings, CollaborationUse and Connections in subExtend Collaboration. 2) What needs to change to reach the expected result? Thanks, George i. binding a role from an inherited part to itself seems useless. Dropping it or adding it would not change the meaning at all since it is the same thing. ii. I don't know what you mean by subsets. All roles are inherited by Extend and SubExtend. I would expect Extend and SubExtend to contain A, B, C, D, E, and F. iii. Binding an inherited role to another part says A, E and D are all playing the same role. Now what would that mean when you created a collaboration use :SubExtend? Would a binding to A, E or D be the same regardless of which role was bound. I don't understand what you are trying to model with this. From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, March 17, 2010 2:19 PM To: Ericson, George Cc: bran.selic@gmail.com; selic@acm.org; uml2-rtf@omg.org Subject: RE: Issue 13452 George, Let's look specifically at the issue: "Assuming one Collaboration represents mandatory features and another Collaboration wants to extend that. It seems natural to express only the differences in the second Collaboration and to use roleBinding to between properties of the extending Collaboration to properties of a CollaborationUse of the first. The implication is that properties of the first collaboration are included as part of the second collaboration, since the CollaborationUse is essentially an instantiation of the first Collaboration in the context of the second. The roleBindings indicate were instances of the properties of first are constrained to be instances of the second Collaboration. This usage would require that the 2nd constraint be modified and that properties of the CollaborationUse of the first Collaboration are interpreted as being incorporated into the second Collaboration except when there is a roleBinding between the properties of the first and second Collaborations. " A Collaboration represents a pattern of interaction between roles (structurally with connectors between the parts/roles of the collaboration and behaviorally using owned behaviors of the collaboration). A Collaboration is a generalizable element, so it can have specializations that add additional roles, connections and behaviors, including redefinitions. A CollaborationUse is a typed element that is essentially an "instance" of a Collaboration. It shows that the containing element (usually a classifier of some sort) adheres to the pattern of interaction described by the interaction. The CollaborationUse role bindings indicate what part of the owner of the collaboration use plays what role in the defining collaboration. So you would expect a specialization of a collaboration to include all its roles and the inherited roles, and a CollaborationUse typed by such a collaboration would need to have role bindings to parts for every one of those roles. I wouldn't expect to see a CollaborationUse for both the general and specific Collaborations in the same context as that would be redundant. If on the other hand, you had a superclass that adhered to a collaboration, you could have a subclass that adheres to the specialized collaboration. Currently there's no way to separate the collaboration use into two parts - just like there's no way to separate an instance of a class into parts representing its superclasses. The same collaboration use couldn't appear in two different classifiers. So I think the resolution to this issue is to specialize the collaboration, and use a collaboration use of the specialized collaboration with all role bindings in one place. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/17/2010 04:56 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- So do you recommend: A) DMTF create a version of a UML Profile for CIM that solves the 13452 issue? a. If so, is it sufficient for this to be a DMTF standard, or must it be an OMG standard? B) OMG extend UML to support merge semantics for Properties of a CollaborationUse? Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, March 17, 2010 11:09 AM To: Ericson, George Cc: bran.selic@gmail.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: Issue 13452 Yes, that would violate that constraint. But other standards are also free to extend UML semantics. SoaML provides a profile and MOF metamodel and extends UML with the isStrict property on collaborations. Any inconsistencies are intended to be addressed by the task force, AB and BOD for standards. The clause in 18.1.2 applies to user profiles, not new standards. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/16/2010 09:03 PM Subject: Re: Issue 13452 -------------------------------------------------------------------------------- The reason this makes me uncomfortable is that we define extension to require conformance to the extended element. The definition you are using implies that conformance is not a requirement. Isn't this at odds with clause 18.1.2 Extensibility that asserts: "It is not possible to take away any constraints that apply to a metamodel such as UML using a profile..." [gme: and thus a stereotype] George -------------------------------------------------------------------------------- From: Jim Amsden To: Ericson, George Cc: bran.selic@gmail.com ; Ericson, George; selic@acm.org ; uml2-rtf@omg.org Sent: Tue Mar 16 15:20:12 2010 Subject: RE: Issue 13452 SoaML extends UML and is free to define whatever semantics it requires - as is any other specification. The isStrict property provides additional flexibility in UML models. If isStrict is true, then the normal UML semantics apply. If it is false, then the SoaML extension applies and the collaboration use role bindings don't need to be complete or type compatible. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS, Cc: , Date: 03/16/2010 05:01 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- I thought about applying the same idea as used by SoaML isStrict to a CollaborationUse stereotype as a means to extend the UML model to cover our case. We could add an isMerge attribute to a stereotype that extends CollaborationUse. However, I am concerned that this approach is not consistent with the UML model, since it seems to violate the UML CollaborationUse constraint: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the classifier or operation. (Similarly, I think the SoaML isStrict attribute of a CollaborationUse stereotype violates the UML model type constraint.) I would appreciate guidance on this topic. Thanks, George From: Ericson, George Sent: Saturday, March 13, 2010 9:54 PM To: Jim Amsden; Bran Selic Cc: bran.selic@gmail.com; uml2-rtf@omg.org Subject: RE: Issue 13452 Jim, Bran, Let me back up and explain the use case Iâm trying to solve. We have a Model that includes some 1000 Classes and 600 AssociationClasses. Note, this model currently does not use any simple Associations. The AssociationClasses own their AssociationEnds. For various uses, we want to select some number of Classes and related AssociationClasses and specify implementation requirements. The UML Collaboration seems most amenable to this, but we have some issues. Each of these Collaborations then represents a pattern, or assembly, specification that an implementation must conform to if it claims support for the use represented by the Collaboration. The implementation can be modeled as a Component. In general, there will be a top level Collaboration that an implementation of a Component conforms to. That top level Collaboration is often built up from one or more sub Collaborations. We want to use this modeling technique to SNIAâs SMI-S profiles and DMTFâs Server Management profiles. So, the sub collaborations will often be nested 3-5 layers deep. In other words, these get very complex. Our problem is that we want to keep the presentation and representation as simple as possible. We are looking to do the following: · Collaborations represent a sub model together with implementation requirements and constraints. These are additive to the requirements of the schema. · Classes in our model are represented by Properties of a Collaboration, with specific requirements and constraints on the methods and properties and cardinality of instances of the Class added to the Collaboration Property. · AssociationClasses are represented by Connections of a Collaboration, with specific requirements and constraints on the methods and properties and multiplicities of the AssociationClass added to the Collaboration Connection. · Sub Collaborations are represented by CollaborationUses. Several problems with this approach have been pointed out: 1) We read the constraint mentioned in the issue 13452 would require that each Collaboration explicitly create Properties to represent every Property of all sub Collaborations, represented by CollaborationUses. This is recursive and while we understand that all of these Properties donât need to be shown in related CompositeStructure diagrams, never-the-less it means that the model contains a large number of Properties that could be implied. While the semantics are slightly different, this is very similar to the same problem solved by PackageMerge that implies the existence of the incorporated Elements, without requiring them all to be modeled in the incorporating Package. a. Where we explicitly create a RoleBinding between a Property and a corresponding Property in a CollaborationUse, we expect that the behaviors, requirements, and constraints on the Property create a subset of the Property in the CollaborationUse. b. Where we explicitly do not create RoleBindings to a Property of a CollaborationUse, we expect that the behaviors, requirements and constraints of that Property are incorporated into the Collaboration that specifies the CollaborationUse. It would be ideal if this is already what you intend for the semantics of CollaborationUse. If not, perhaps a boolean attribute could be added to the CollaborationUse that specifies this behavior. 2) We read the model for Connector to allow the type to be an AssociationClass, but this is somewhat controversial and not well-supported by the UML tool industry. 3) We read RoleBinding as an alternative representation of Subset relationship between properties. However, subsetting is not currently directly supported between properties within a Collaboration. In our models, a common case where this occurs is where we want to include but Classes and Sub Classes of that class into a Collaboration. Often with additional Connections. It is possible to recursively reference a Collaboration as a CollaborationUse to solve this problem, but that seems somewhat awkward. The Generalization relationship would be a natural addition to the Collaboration Model to represent this. For now, Issue 1 is the primary show-stopper. Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, March 13, 2010 8:03 AM To: Bran Selic Cc: bran.selic@gmail.com; Ericson, George; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran Subject: Re: Issue 13452 Date: Fri, 19 Mar 2010 08:51:00 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Issue 13452 Thread-Index: AcrHHM73zJAoNvprQBGOY0ToqoH0KgARgT0O From: To: Cc: , , X-OriginalArrivalTime: 19 Mar 2010 12:51:04.0256 (UTC) FILETIME=[D5E1FC00:01CAC762] X-EMM-EM: Active Jim, Keep in mind that this example was meant to explore your idea of using generalization between collaborations. On use of composite structure diagram: I find the limitations of the colaboration oval too frustrating so I generally use the more space efficient composite structure diagram. On lack of detail. Assume that each Property has a class of the same name. Assume that D and E are either the same as, or a subclass of A. Assume that constraints and requirements of D and E are consistent with those of A. If you want, consider A, B, C, D, E, F to be Musician, Director, Actor, Pianist, Harpist, Assistant. I didn't show multiplicities, but assume one Director(B), multiple otherwise. The intention of the condensed view is to show that Pianist and Harpist each play the role of a Musician in Base. The expanded view shows the problem with using Generalization, since the intention is to replace the more general Role Musician(A) with the more specific Roles, Pianist(D)and Harpist(E). Both should be connected to Director(B) and to Assistant(F). Director(B) should continue to be connected to Actor(C). However, instead we see that Musician(A) is still part of the colaboration. And that the connections haven't been propagated. (This may be a problem with the tool I'm using.) I continued to use the Base collaboration use in Extend because I don't know any other way to express the subset relationship that I believe is implied by the RoleBinding. G -------------------------------------------------------------------------------- From: Jim Amsden To: Ericson, George Cc: bran.selic@gmail.com ; selic@acm.org ; uml2-rtf@omg.org Sent: Fri Mar 19 00:29:19 2010 Subject: RE: Issue 13452 George, I don't understand the example. Comments embedded below... Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/17/2010 10:13 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- This is an interesting idea. I tried it out with three Collaborations with a UML tool that I think does a pretty good job of following the UML specification: So you have a Collaboration Base which defines some pattern of interaction between its (so far unspecified) roles. This is extended with Collaboration Extension which presumably adds more roles or different interactions. That is in turn specialized somehow with SubExtension. So far, this is an under-specified model since we don't know the roles or what the extensions actually are. Collaboration: Base I'm not exactly sure of the notation being used here, but I assume this is an structure diagram for collaboration Base (instead of showing the roles in the collaboration which would be the usual notation, but this is not incorrect). So we see there are three roles, with A connected to B and B connected to C, but we don't know anything about the roles - their types or the behaviors of collaboration base to indicate how the roles are intended to interact. Again, this is a bit under-specified, so it will be hard to know that the specializations might mean. Collaboration: Extend (condensed view) Now this is strange. You have a collaboration Extension which specializes Base and therefore has roles A, B and C plus their connections. This adds new roles D, E, and F with their connections. The collaboration use :Base makes no sense here. It is binding roles to inherited parts, and the role B is not bound. D and E are bound to role A, which is also part of Extension since they are inherited. Why have Extension inherit from Base and conform partially to the pattern of interactions specified by Base? That seems both incomplete and possibly redundant. Extension already contains A, B and C with their connections, why have additional roles that somehow overlap through the bindings with inherited roles? I suppose this is legal, but it seems pretty contrived and unusual. Can you provide a more realistic example? Collaboration: Extend (expanded view) Yes, but what does this mean? Why do D and E have multiple bindings to A? What plays the B and C role in Extension - inherited B and C? If you remove the collaboration use :Base from the Extension collaboration, then you would be defining a collaboration that specializes another collaboration by adding roles D, E and F. That seems fine. Anything that adheres to collaboration Base would have a collaboration use :Base with role bindings to A, B and C. Anything that adhered to the collaboration Extension would have role bindings for A, B, C, D, E and F. That seems pretty straight forward. Collaboration: SubExtend SubExtension appears identical to Extension given the available information. These results are not quite what I expect. The expected result would be: The tool seems to be inferring that an inherited role is a part that automatically binds to the collaboration use of its general collaboration. Again, this seems to me to have little value, and I have no idea if it is valid UML or not. Certainly the role bindings can be made, and inherited role C would certainly be compatible with the role it is bound to since it is the same thing. But this makes no sense. Perhaps you could provide a more realistic example explaining what you're trying to do? So, at least for this tool, your suggestion doesnât produce the desired results. My questions are: 1) Did the tool follow the specification correctly? a. I think there are some issues. i. Dropped and Extra Role Bindings and dropped Connections in expanded view ii. Property A carried into Extend and SubExtend. My expectation was that only the subsets named by E and D should be present. iii. Dropped Role Bindings, CollaborationUse and Connections in subExtend Collaboration. 2) What needs to change to reach the expected result? Thanks, George i. binding a role from an inherited part to itself seems useless. Dropping it or adding it would not change the meaning at all since it is the same thing. ii. I don't know what you mean by subsets. All roles are inherited by Extend and SubExtend. I would expect Extend and SubExtend to contain A, B, C, D, E, and F. iii. Binding an inherited role to another part says A, E and D are all playing the same role. Now what would that mean when you created a collaboration use :SubExtend? Would a binding to A, E or D be the same regardless of which role was bound. I don't understand what you are trying to model with this. From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, March 17, 2010 2:19 PM To: Ericson, George Cc: bran.selic@gmail.com; selic@acm.org; uml2-rtf@omg.org Subject: RE: Issue 13452 George, Let's look specifically at the issue: "Assuming one Collaboration represents mandatory features and another Collaboration wants to extend that. It seems natural to express only the differences in the second Collaboration and to use roleBinding to between properties of the extending Collaboration to properties of a CollaborationUse of the first. The implication is that properties of the first collaboration are included as part of the second collaboration, since the CollaborationUse is essentially an instantiation of the first Collaboration in the context of the second. The roleBindings indicate were instances of the properties of first are constrained to be instances of the second Collaboration. This usage would require that the 2nd constraint be modified and that properties of the CollaborationUse of the first Collaboration are interpreted as being incorporated into the second Collaboration except when there is a roleBinding between the properties of the first and second Collaborations. " A Collaboration represents a pattern of interaction between roles (structurally with connectors between the parts/roles of the collaboration and behaviorally using owned behaviors of the collaboration). A Collaboration is a generalizable element, so it can have specializations that add additional roles, connections and behaviors, including redefinitions. A CollaborationUse is a typed element that is essentially an "instance" of a Collaboration. It shows that the containing element (usually a classifier of some sort) adheres to the pattern of interaction described by the interaction. The CollaborationUse role bindings indicate what part of the owner of the collaboration use plays what role in the defining collaboration. So you would expect a specialization of a collaboration to include all its roles and the inherited roles, and a CollaborationUse typed by such a collaboration would need to have role bindings to parts for every one of those roles. I wouldn't expect to see a CollaborationUse for both the general and specific Collaborations in the same context as that would be redundant. If on the other hand, you had a superclass that adhered to a collaboration, you could have a subclass that adheres to the specialized collaboration. Currently there's no way to separate the collaboration use into two parts - just like there's no way to separate an instance of a class into parts representing its superclasses. The same collaboration use couldn't appear in two different classifiers. So I think the resolution to this issue is to specialize the collaboration, and use a collaboration use of the specialized collaboration with all role bindings in one place. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/17/2010 04:56 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- So do you recommend: A) DMTF create a version of a UML Profile for CIM that solves the 13452 issue? a. If so, is it sufficient for this to be a DMTF standard, or must it be an OMG standard? B) OMG extend UML to support merge semantics for Properties of a CollaborationUse? Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, March 17, 2010 11:09 AM To: Ericson, George Cc: bran.selic@gmail.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: Issue 13452 Yes, that would violate that constraint. But other standards are also free to extend UML semantics. SoaML provides a profile and MOF metamodel and extends UML with the isStrict property on collaborations. Any inconsistencies are intended to be addressed by the task force, AB and BOD for standards. The clause in 18.1.2 applies to user profiles, not new standards. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: Jim Amsden/Raleigh/IBM@IBMUS Cc: , , Date: 03/16/2010 09:03 PM Subject: Re: Issue 13452 -------------------------------------------------------------------------------- The reason this makes me uncomfortable is that we define extension to require conformance to the extended element. The definition you are using implies that conformance is not a requirement. Isn't this at odds with clause 18.1.2 Extensibility that asserts: "It is not possible to take away any constraints that apply to a metamodel such as UML using a profile..." [gme: and thus a stereotype] George -------------------------------------------------------------------------------- From: Jim Amsden To: Ericson, George Cc: bran.selic@gmail.com ; Ericson, George; selic@acm.org ; uml2-rtf@omg.org Sent: Tue Mar 16 15:20:12 2010 Subject: RE: Issue 13452 SoaML extends UML and is free to define whatever semantics it requires - as is any other specification. The isStrict property provides additional flexibility in UML models. If isStrict is true, then the normal UML semantics apply. If it is false, then the SoaML extension applies and the collaboration use role bindings don't need to be complete or type compatible. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: To: , Jim Amsden/Raleigh/IBM@IBMUS, Cc: , Date: 03/16/2010 05:01 PM Subject: RE: Issue 13452 -------------------------------------------------------------------------------- I thought about applying the same idea as used by SoaML isStrict to a CollaborationUse stereotype as a means to extend the UML model to cover our case. We could add an isMerge attribute to a stereotype that extends CollaborationUse. However, I am concerned that this approach is not consistent with the UML model, since it seems to violate the UML CollaborationUse constraint: [2] Every role in the collaboration is bound within the collaboration use to a connectable element within the classifier or operation. (Similarly, I think the SoaML isStrict attribute of a CollaborationUse stereotype violates the UML model type constraint.) I would appreciate guidance on this topic. Thanks, George From: Ericson, George Sent: Saturday, March 13, 2010 9:54 PM To: Jim Amsden; Bran Selic Cc: bran.selic@gmail.com; uml2-rtf@omg.org Subject: RE: Issue 13452 Jim, Bran, Let me back up and explain the use case Iâm trying to solve. We have a Model that includes some 1000 Classes and 600 AssociationClasses. Note, this model currently does not use any simple Associations. The AssociationClasses own their AssociationEnds. For various uses, we want to select some number of Classes and related AssociationClasses and specify implementation requirements. The UML Collaboration seems most amenable to this, but we have some issues. Each of these Collaborations then represents a pattern, or assembly, specification that an implementation must conform to if it claims support for the use represented by the Collaboration. The implementation can be modeled as a Component. In general, there will be a top level Collaboration that an implementation of a Component conforms to. That top level Collaboration is often built up from one or more sub Collaborations. We want to use this modeling technique to SNIAâs SMI-S profiles and DMTFâs Server Management profiles. So, the sub collaborations will often be nested 3-5 layers deep. In other words, these get very complex. Our problem is that we want to keep the presentation and representation as simple as possible. We are looking to do the following: · Collaborations represent a sub model together with implementation requirements and constraints. These are additive to the requirements of the schema. · Classes in our model are represented by Properties of a Collaboration, with specific requirements and constraints on the methods and properties and cardinality of instances of the Class added to the Collaboration Property. · AssociationClasses are represented by Connections of a Collaboration, with specific requirements and constraints on the methods and properties and multiplicities of the AssociationClass added to the Collaboration Connection. · Sub Collaborations are represented by CollaborationUses. Several problems with this approach have been pointed out: 1) We read the constraint mentioned in the issue 13452 would require that each Collaboration explicitly create Properties to represent every Property of all sub Collaborations, represented by CollaborationUses. This is recursive and while we understand that all of these Properties donât need to be shown in related CompositeStructure diagrams, never-the-less it means that the model contains a large number of Properties that could be implied. While the semantics are slightly different, this is very similar to the same problem solved by PackageMerge that implies the existence of the incorporated Elements, without requiring them all to be modeled in the incorporating Package. a. Where we explicitly create a RoleBinding between a Property and a corresponding Property in a CollaborationUse, we expect that the behaviors, requirements, and constraints on the Property create a subset of the Property in the CollaborationUse. b. Where we explicitly do not create RoleBindings to a Property of a CollaborationUse, we expect that the behaviors, requirements and constraints of that Property are incorporated into the Collaboration that specifies the CollaborationUse. It would be ideal if this is already what you intend for the semantics of CollaborationUse. If not, perhaps a boolean attribute could be added to the CollaborationUse that specifies this behavior. 2) We read the model for Connector to allow the type to be an AssociationClass, but this is somewhat controversial and not well-supported by the UML tool industry. 3) We read RoleBinding as an alternative representation of Subset relationship between properties. However, subsetting is not currently directly supported between properties within a Collaboration. In our models, a common case where this occurs is where we want to include but Classes and Sub Classes of that class into a Collaboration. Often with additional Connections. It is possible to recursively reference a Collaboration as a CollaborationUse to solve this problem, but that seems somewhat awkward. The Generalization relationship would be a natural addition to the Collaboration Model to represent this. For now, Issue 1 is the primary show-stopper. Thanks, George From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, March 13, 2010 8:03 AM To: Bran Selic Cc: bran.selic@gmail.com; Ericson, George; uml2-rtf@omg.org Subject: Re: Issue 13452 Bran, I think I understand what George is saying. A Collaboration can be considered part of the type system because of the binding of a part to a role in a collaboration through a collaboration use. The implication is the part must be type compatible with the role it is bound to. This allows collaborations to define patterns of interaction between parts for requirements (option instead of use cases), contract, descriptive, architectural, or pattern purposes. But there are cases where the collaboration use and role bindings need not imply strict type compatibility, but rather information describing a requirements rather than something that is intended to explicitly constrain the bound parts. SoaML had the same requirement and introduced a property isStrict to effectively turn off type checking in collaboration role bindings. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: ericson_george@emc.com Cc: uml2-rtf@omg.org Date: 03/13/2010 07:07 AM Subject: Re: Issue 13452 Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- George, You wrote: On Fri, Mar 12, 2010 at 4:16 PM, wrote: This issue was raised: January 30, 2009. We understand that the CollaborationUse may be interpreted as only representing a type system. [bvs] Could you please explain the above statement? As one of the authors of this part of the spec, it is not an interpretation I recognize. In what way does a collaboration use represent a type system? However, a second interpretation is as a description of aspects of the containing classifier, (see 9.3.2 Classifier sub clause Semantics). [bvs] This is a perfectly valid application of the collaboration use concept. Is anyone disputing it? Under the second interpretation, the requirement to replicate every Property of a Collaboration incorporated via CollaborationUse in the incorporating Classifier is extremely onerous when composing complex Collaborations utilizing multiple sub-collaborations. The underlying assumption has to be that Properties named in a Collaboration are there for purpose and not simply to define a type system. The analogy is Assemblies and Sub Assemblies. [bvs] Can you please provide an example of what you are talking about? I am having some difficulty trying to understand what you are talking about. Thanks...Bran