Issue 6146: Composite structure dependent on Behavior (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: Composite structure uses Classifier from Communications, but composite structure should be usable without behavior. Resolution: Revised Text: Actions taken: August 30, 2003: received issue March 9, 2005: closed issue Discussion: Actually, none of the packages in the composite structure chapter rely on Communications::Classifier directly. But if by “Composite structure” the issue is referring to the whole chapter on Composite structure, then it is difficult to understand what the concern is. Various subpackages described in this chapter necessarily rely on the Communications package, such as InvocationActions or Ports, so these packages cannot be used without Behaviors (they inherently involve behavior). Communications (from CommonBehaviors) InternalStructures Ports Interfaces (from Classes) <<merge>> <<merge>> <<merge>> InvocationActions <<merge>> <<merge>> <<merge>> StructuredClasses <<merge>> <<merge>> As can be seen above, StructuredClasses depends on Communications in two ways: Through Ports and directly. The issue suggests that by deleting the dependency between StructuredClass and Communications due to Communications::Class, one does not depend on Communications. However, one will still have the dependency through Ports. This is for good reasons, as Ports require Communications (they reference Receptions, which are introduced in Communications). I assume that the issue, however, is referring to StructuredClasses::Class. This class is a subtype of Communications::Class and of EncapsulatedClassifier. Again, it relies on the Behavior package, but by design. The reason why Class from communciations is taken is that StructuredClasses::Class should be (i) be able to have ports, i.e., be an encapsulated classifier, and (ii) be able to have behavior, i.e., be a behaviored classifier. Only due to the latter do the additions of ports by inheriting from EncapsulatedClassifier make sense. This allows, for example, to associate interactions as behaviors with the class. The issue states that “composite structure should be usable without behavior.” If “composite structure” refers to the internal structure of a classifier, this is already the case. If “composite structure” refers to a classifier that also has ports, this is not possible, as the definition of ports already refers to behavior. Profiles that want to introduce a new kind of class that can have ports, but no behavior (somewhat nonsensical, but be that as it may), can easily do so. Disposition: Closed, no change End of Annotations:===== Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Composite structure dependent on Behavior Composite structure uses Classifier from Communications, but composite structure should be usable without behavior. Discussion: Actually, it is only the sub-package StructuredClasses that relies on package Communications. StructuredClasses::Class is meant to be a subtype of Communications::Class, having the ability to own receptions and the isActive attribute. If a profile requires a different subclass of EncapsulatedClassifier that is not a Communications::Class, it can easily introduce such metaclass. Disposition: Closed, no change OMG Issue No: 6146 Title: Composite structure dependent on Behavior Source: Kabira Technologies, Inc.NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Composite structure uses Classifier from Communications, but composite structure should be usable without behavior. Discussion: Actually, it is only the sub-package StructuredClasses that relies on package Communications. StructuredClasses::Class is meant to be a subtype of Communications::Class, having the ability to own receptions and the isActive attribute. If a profile requires a different subclass of EncapsulatedClassifier that is not a Communications::Class, it can easily introduce such metaclass. [Conrad: Why is it necessary for StructuredClasses to rely on communications? The entry for Class, section 9.3.1, doesn't explain. There should be a definition of structured class that doesn't depend on the behavior packages, even if it is a new package.] Disposition: Closed, no change OMG Issue No: 6146 Title: Composite structure dependent on Behavior Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Composite structure uses Classifier from Communications, but composite structure should be usable without behavior. Discussion: Actually, none of the packages in the composite structure chapter rely on Communications::Classifier directly. But if by .Composite structure. the issue is referring to the whole chapter on Composite structure, then it is difficult to understand what the concern is. Various subpackages described in this chapter necessarily rely on the Communications package, such as InvocationActions or Ports, so these packages cannot be used without Behaviors (they inherently involve behavior). I assume that the issue, however, is referring to StructuredClasses::Class. This class is a subtype of Communications::Class and of EncapsulatedClassifier. Again, it relies on the Behavior package, but by design. Disposition: Closed, no change To: "Thomas Weigert" Cc: "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: ,cs cb, Ballot 13 proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 22 Apr 2004 16:57:33 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/22/2004 16:57:35, Serialize complete at 04/22/2004 16:57:35 Thomas, I have reviewed your proposed resolutions for ballot 13 and have the following comments and concerns: (1) Issue 6078: (a) from your explanation, it looks to me that the vertical bar -- indicating choice -- in the expression: ref interactionident | [strict] is incorrect and should be removed. (b) it seems that the information that the inline decomposition is strict is only kept in the notation and not in the model. Presumably, this information is somehow transferred into some interaction operator of some combined fragment of the part decomposition corresponding to the lifeline -- however, how this is done is not described. This needs to be clarified. (2) Issue 6146: I agree with your "closed, no change" disposition, but I think your explanation is missing at least one major point. I believe that the question primarily related to the fact that Collaboration is defined as a kind of BehavioredClassifier -- which is perfectly reasonable since we want to be able to associate Interactions with Collaborations. It would be useful if this was added to the resolution. (3) Issue 6154: The text in the Semantics part of TimeObservationAction says that this action, "...when executed, returns the current value of time in the context in which....". I suggest replacing the word "returns" in this text with the word "reads" or "registers". Otherwise, it seems to clash with the fact that this action, being a write action does not have return values. (An aside: I should have been paying attention to this when it was being done in the U2P. Why should this action be restricted to just write-once-attributes? Why not make it more general? This seems like a piece of an SDL profile that snuck in under the radar.) (4) Issue 6251: I sent you an OCL constraint that effectively said that all roles that are connected by a connector have to be in the same Classifier (namespace). This also resolves issue 6668. So, I suggest that you change this to "resolved" and add my constraint. (In fact, the fix I sent you also includes a nice illustration which is a bit easier to follow than your textual explanation, so I suggest you replace the resolution with the one I proposed.) (5) Issue 6257: It would really help me and others if in the future you could put a figure number for the diagram that you want to change -- it makes it a lot easier to review the resolution proposal and to make the change once it is adopted. (I assume you mean figure 318 in this case?) (6) Issue 6355: I don't think that "Duplicate" is the right resolution to this issue. What happened here is that the reader who read the spec missed the rather convoluted "trick" that is used to specify when a connector end is connected to a port. The trick is used to avoid a "PortReference" concept, by providing a link to a part that owns the port that is being connected when the connector terminates on a port of some part (i.e., if this link is nil, then the connector terminates on a port or part, otherwise, it terminates on the port of a part, and you know which it is based on which port the connector end is linked to). This is very subtle and will be confusing to many unless additional text is provided. (7) Issue 6668: See my comment for issue 6251. Cheers, Bran "Thomas Weigert" 04/21/2004 04:33 PM To "Thomas Weigert" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: ,cs cb, Ballot 13 proposed resolutions Please find attached an additional issue resolution (included in the pack sent earlier)... Th -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Monday, April 19, 2004 11:27 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org Subject: ,cs cb, Ballot 13 proposed resolutions Please find attached the first installment of Ballot 13 proposals (I think that is the next ballot). All the best, Th.[attachment "Comp struc + com beh issues 3rd v2 done.doc" deleted by Branislav Selic/Ottawa/IBM] Reply-To: From: "Conrad Bock" To: Subject: RE: ,cs cb, Ballot 13 proposed resolutions Date: Sun, 25 Apr 2004 10:52:50 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas. Here are comments on cb/cs proposals for ballot 13. Conrad - 6146 (Composite structure dependent on Behavior) I was referring to the dependency of StructuredClasses on Behavior introduced by Figure 98. A structured class should be able to be used in implementations that only implement structure. Communication is not the only application for associations and connectors (see Joaquin's example of an association not used for communication). - 6154 (TimeObservationAction can't return values) The proposed semantics text for TimeObservationAction still says "returns a value". If this were removed, as it is in DurationObservationAction, it would be fine. - 6251 (UML 2 super/Composite Classes/Connecting parts of parts) This is an unnecessary restriction. Parts of parts should be connectable without going through ports. partWithPort should be able to connect parts of parts without needing to use ports. Just loosen constraint 2 of ConnectorEnd to allow all parts. - 6458 (Change 'Part' to 'Role) The discussion acknowledges the issue and cites the amount of work to resolve it, but then closes it without change. How about deferring on that basis, instead? - 6668 (UML2 Super/Connector) The discussion refers to adtf/03-08-02, which doesn't exist (and ad/03-08-02 is a MOF QVT review). Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: ,cs cb, More Ballot 14 proposed resolutions, 6146 Date: Wed, 12 May 2004 14:30:19 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, Did you have a response to this? Below is an alternate resolution. Conrad -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Sunday, May 09, 2004 9:34 AM To: uml2-superstructure-ftf@omg.org Subject: RE: ,cs cb, Ballot 14 proposed resolutions Thomas, See below for comments on your proposal for 6146 (Composite structure dependent on Behavior). It is still methodologically restrictive. The needed change supports current functionality and does not require structure to depend on behavior, as it does in your methodology: Figure 98: Replace Class (from Communications) with Class (from Kernel). Figure 94: Remove dependency from StructuredClasses to Commmunications. Vendors implementing Class from Communications get behavior by package merge. Comments on the ballot below, Conrad 6146 (Composite structure dependent on Behavior) > [Issue] Composite structure uses Classifier from Communications, but > composite structure should be usable without behavior. > [Discussion] The issue is incorrect in asserting that composite > structure uses Communications::Classifier. You're right, it uses Communications::Class. The point is the same. > The issue also makes the suggestion that composite structure should > be usable without behavior. This suggestion is difficult to > understand, as it is not clear what "composite structure" refers > to. I was referring Figure 98, StructuredClasses, as you explain below, which is the only one that provides a concrete class with composite structure. > If it refers to the Composite Structure chapter in the > specification, this suggestion does not make sense, as packages such > as InvocationActions or Ports inherently rely on the Communications > package, and thus also on "behavior" (assuming that this refers to > the CommonBehaviors package. > The features in these packages inherently involve behavior, so > suggesting that they not rely on behavior is not quite feasible. Then these can depend on CommonBehavior, but not all of StructuredClasses, as shown already in Figure 94. > Another interpretation would be that the issue is actually referring > to StructuredClasses::Class. This class is a subtype of > Communications::Class and of EncapsulatedClassifier. Again, it relies > on the Behavior package by design. The reason why Class from > communciations is taken is that StructuredClasses::Class should be > able to have behavior, i.e., be a behaviored classifier and have > Receptions as behavioral features. Sure, and that happens when Behavior::Communications is implemented, by package merge. > Only so do the additions of ports by inheriting from > EncapsulatedClassifier make sense. This allows, for example, to > associate interactions as behaviors with the class. Ports can be associatied without behavior implementing the operations on the port. From: "Thomas Weigert" To: , "uml2ftf" Subject: RE: ,cs cb, More Ballot 14 proposed resolutions, 6146 Date: Wed, 12 May 2004 15:29:36 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Conrad, regarding your suggestion: 1. Below the relevant package hierarchy for StructuredClasses: As you can see, StructuredClasses depends on Communications in two ways: Through Ports and directly. As a technical aside, your suggest that by deleting the dependency between StructuredClass and Communications due to Communications::Class, you do not depend on Communications. As you can see, you still have the dependency through Ports. This is through good reasons, as Ports require Communications (they reference Receptions, which are introduced in Communications). 2. Below find the whole content of StructuredClasses: The point of structured class is to have a class that (i) has ports and (ii) is a behaviored classifier. This is achieved by the above diagram. Consequentially, no change is recommended. Note that this is a good example of how to build up the hierarchy. It is easy to add another class which is not a behaviored classifier as you suggest below in a profile. Contrast this with the activities example we have been discussing where it is not possible to create a profile that only uses actions, but does not introduce flows at the same time, and all kinds of other gimmicks. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Wednesday, May 12, 2004 1:30 PM > To: uml2ftf > Subject: ,cs cb, More Ballot 14 proposed resolutions, 6146 > > > > Thomas, > > Did you have a response to this? Below is an alternate > resolution. > > Conrad > > > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, May 09, 2004 9:34 AM > To: uml2-superstructure-ftf@omg.org > Subject: RE: ,cs cb, Ballot 14 proposed resolutions > > > Thomas, > > See below for comments on your proposal for 6146 (Composite structure > dependent on Behavior). It is still methodologically restrictive. > > The needed change supports current functionality and does not require > structure to depend on behavior, as it does in your methodology: > > Figure 98: Replace Class (from Communications) with Class (from > Kernel). > > Figure 94: Remove dependency from StructuredClasses to > Commmunications. > > Vendors implementing Class from Communications get behavior by package > merge. > > Comments on the ballot below, > > Conrad > > > 6146 (Composite structure dependent on Behavior) > > > [Issue] Composite structure uses Classifier from > Communications, but > > composite structure should be usable without behavior. > > > [Discussion] The issue is incorrect in asserting that composite > > structure uses Communications::Classifier. > > You're right, it uses Communications::Class. The point is the same. > > > The issue also makes the suggestion that composite structure should > > be usable without behavior. This suggestion is difficult to > > understand, as it is not clear what "composite structure" refers > > to. > > I was referring Figure 98, StructuredClasses, as you explain below, > which is the only one that provides a concrete class with composite > structure. > > > If it refers to the Composite Structure chapter in the > > specification, this suggestion does not make sense, as > packages such > > as InvocationActions or Ports inherently rely on the Communications > > package, and thus also on "behavior" (assuming that this refers to > > the CommonBehaviors package. > > The features in these packages inherently involve behavior, so > > suggesting that they not rely on behavior is not quite feasible. > > Then these can depend on CommonBehavior, but not all of > StructuredClasses, as shown already in Figure 94. > > > Another interpretation would be that the issue is actually > referring > > to StructuredClasses::Class. This class is a subtype of > > Communications::Class and of EncapsulatedClassifier. > Again, it relies > > on the Behavior package by design. The reason why Class from > > communciations is taken is that StructuredClasses::Class should be > > able to have behavior, i.e., be a behaviored classifier and have > > Receptions as behavioral features. > > Sure, and that happens when Behavior::Communications is > implemented, by > package merge. > > > Only so do the additions of ports by inheriting from > > EncapsulatedClassifier make sense. This allows, for example, to > > associate interactions as behaviors with the class. > > Ports can be associatied without behavior implementing the > operations on the port. > clip_image0021.gif clip_image0022.gif From: "Thomas Weigert" To: , Subject: RE: ,cs cb, Ballot 13 proposed resolutions Date: Tue, 27 Apr 2004 22:15:32 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Conrad, comments to your comments... > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > > - 6146 (Composite structure dependent on Behavior) > > I was referring to the dependency of StructuredClasses on Behavior > introduced by Figure 98. A structured class should be able to be > used in implementations that only implement structure. Communication > is not the only application for associations and connectors (see > Joaquin's example of an association not used for communication). Sure. Except Figure 98 defines a Class which is both EncapsulatedClassifier and Class. If you want a different kind of concrete subtype for StructuredClassifier, it is easy to define one. Note that both EncapsulatedClassifier and Communications::Class inherit from Communications. > > > - 6154 (TimeObservationAction can't return values) > > The proposed semantics text for TimeObservationAction still says > "returns a value". If this were removed, as it is in > DurationObservationAction, it would be fine. Sorry. Fixed now. > > > - 6251 (UML 2 super/Composite Classes/Connecting parts of parts) > > This is an unnecessary restriction. Parts of parts should be > connectable without going through ports. partWithPort should be able > to connect parts of parts without needing to use ports. Just loosen > constraint 2 of ConnectorEnd to allow all parts. Well, that's how structured classes were designed intentionally. > > > - 6458 (Change 'Part' to 'Role) > > The discussion acknowledges the issue and cites the amount of work to > resolve it, but then closes it without change. How about deferring > on that basis, instead? Actually, the discussion did not "acknowledge" the issue in the sense of accepting it. Rather it says that part and role are not synonymous, and while there are situations that one could use the term role where part is meant, this is not true throughout. In a sense, the issue just says, "I don't like this word, why don't you use this other word". As there are many other terms in the UML that overlap with common sense terms, without a systematic program of replacing them all, there seems little reason to start here. > > > - 6668 (UML2 Super/Connector) > > The discussion refers to adtf/03-08-02, which doesn't exist (and > ad/03-08-02 is a MOF QVT review). From: "Thomas Weigert" To: "Thomas Weigert" , "Branislav Selic" , Subject: ,cs cb, Ballot 14 proposed resolutions Date: Tue, 4 May 2004 15:28:26 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Attached please find the first installment of proposed solutions for Ballot 14. Comments: 6146: This solution was contested in last ballot. I rewrote the discussion to be clearer. However, I find the objection inappropriate and am still suggesting to close this issue with no change. 6251: An earlier objection had suggested to add a constraint [4] to connector. In the meantime, the resolution to 6668 (adopted in Ballot 12) has added a constraint [4] very similar to the one proposed. The OCL suggested by the objection, however, does not match the adopted constraint exactly. I'd gladly add the modified OCL to [4] if it is provided. Otherwise this issue should be closed. All the best, Th. OMG Issue No: 6146 Title: Composite structure dependent on Behavior Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Composite structure uses Classifier from Communications, but composite structure should be usable without behavior. Discussion: The issue is incorrect in asserting that composite structure uses Communications::Classifier. The issue also makes the suggestion that composite structure should be usable without behavior. This suggestion is difficult to understand, as it is not clear what .composite structure. refers to. If it refers to the Composite Structure chapter in the specification, this suggestion does not make sense, as packages such as InvocationActions or Ports inherently rely on the Communications package, and thus also on .behavior. (assuming that this refers to the CommonBehaviors package. The features in these packages inherently involve behvavior, so suggesting that they not rely on behavior is not quite feasible. Another interpretation would be that the issue is actually referring to StructuredClasses::Class. This class is a subtype of Communications::Class and of EncapsulatedClassifier. Again, it relies on the Behavior package by design. The reason why Class from communciations is taken is that StructuredClasses::Class should be able to have behavior, i.e., be a behaviored classifier and have Receptions as behavioral features. Only so do the additions of ports by inheriting from EncapsulatedClassifier make sense. This allows, for example, to associate interactions as behaviors with the class. Disposition: Closed, no change Reply-To: From: "Conrad Bock" To: , , Subject: RE: Ballot 13 - Vote starts at 6 PM EDT Date: Fri, 30 Apr 2004 11:14:02 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Thomas never responded to my alternative proposal on 6146 (Composite structure dependent on Behavior), so I would like it withdrawn from the ballot. In particular, he hasn't shown any problem with my proposal, which has the same functionality as his, but is not methodologically restrictive. It is: In Figure 98, replace Class (from Communications) with Class (from Kernel). This allows vendors not implementing Communications to use composite structure (they currently cannot). Vendors implementing Communications will merge that class functionality into class, and it will be available in composite structures. Conrad OMG Issue No: 6146 Title: Composite structure dependent on Behavior Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Composite structure uses Classifier from Communications, but composite structure should be usable without behavior. Discussion: Actually, none of the packages in the composite structure chapter rely on Communications::Classifier directly. But if by .Composite structure. the issue is referring to the whole chapter on Composite structure, then it is difficult to understand what the concern is. Various subpackages described in this chapter necessarily rely on the Communications package, such as InvocationActions or Ports, so these packages cannot be used without Behaviors (they inherently involve behavior). I assume that the issue, however, is referring to StructuredClasses::Class. This class is a subtype of Communications::Class and of EncapsulatedClassifier. Again, it relies on the Behavior package, but by design. The reason why Class from communciations is taken is that StructuredClasses::Class should be able to have behavior, i.e., be a behaviored classifier. Only so do the additions of ports by inheriting from EncapsulatedClassifier make sense. This allows, for example, to associate interactions as behaviors with the class. Reply-To: From: "Conrad Bock" To: Subject: RE: ,cs cb, Ballot 14 proposed resolutions Date: Sun, 9 May 2004 09:33:50 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, See below for comments on your proposal for 6146 (Composite structure dependent on Behavior). It is still methodologically restrictive. The needed change supports current functionality and does not require structure to depend on behavior, as it does in your methodology: Figure 98: Replace Class (from Communications) with Class (from Kernel). Figure 94: Remove dependency from StructuredClasses to Commmunications. Vendors implementing Class from Communications get behavior by package merge. Comments on the ballot below, Conrad 6146 (Composite structure dependent on Behavior) > [Issue] Composite structure uses Classifier from Communications, but > composite structure should be usable without behavior. > [Discussion] The issue is incorrect in asserting that composite > structure uses Communications::Classifier. You're right, it uses Communications::Class. The point is the same. > The issue also makes the suggestion that composite structure should > be usable without behavior. This suggestion is difficult to > understand, as it is not clear what "composite structure" refers > to. I was referring Figure 98, StructuredClasses, as you explain below, which is the only one that provides a concrete class with composite structure. > If it refers to the Composite Structure chapter in the > specification, this suggestion does not make sense, as packages such > as InvocationActions or Ports inherently rely on the Communications > package, and thus also on "behavior" (assuming that this refers to > the CommonBehaviors package. > The features in these packages inherently involve behavior, so > suggesting that they not rely on behavior is not quite feasible. Then these can depend on CommonBehavior, but not all of StructuredClasses, as shown already in Figure 94. > Another interpretation would be that the issue is actually referring > to StructuredClasses::Class. This class is a subtype of > Communications::Class and of EncapsulatedClassifier. Again, it relies > on the Behavior package by design. The reason why Class from > communciations is taken is that StructuredClasses::Class should be > able to have behavior, i.e., be a behaviored classifier and have > Receptions as behavioral features. Sure, and that happens when Behavior::Communications is implemented, by package merge. > Only so do the additions of ports by inheriting from > EncapsulatedClassifier make sense. This allows, for example, to > associate interactions as behaviors with the class. Ports can be associatied without behavior implementing the OMG Issue No: 6146 Title: Composite structure dependent on Behavior Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Composite structure uses Classifier from Communications, but composite structure should be usable without behavior. Discussion: The issue is incorrect in asserting that composite structure uses Communications::Classifier. The issue also makes the suggestion that composite structure should be usable without behavior. This suggestion is difficult to understand, as it is not clear what .composite structure. refers to. If it refers to the Composite Structure chapter in the specification, this suggestion does not make sense, as packages such as InvocationActions or Ports inherently rely on the Communications package, and thus also on .behavior. (assuming that this refers to the CommonBehaviors package. The features in these packages inherently involve behavior, so suggesting that they not rely on behavior is not quite feasible. Another interpretation would be that the issue is actually referring to StructuredClasses::Class. This class is a subtype of Communications::Class and of EncapsulatedClassifier. Again, it relies on the Behavior package by design. The reason why Class from communciations is taken is that StructuredClasses::Class should be able to have behavior, i.e., be a behaviored classifier and have Receptions as behavioral features. Only so do the additions of ports by inheriting from EncapsulatedClassifier make sense. This allows, for example, to associate interactions as behaviors with the class. Disposition: Closed, no change OMG Issue No: 6146 Title: Composite structure dependent on Behavior Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Composite structure uses Classifier from Communications, but composite structure should be usable without behavior. Discussion: Actually, none of the packages in the composite structure chapter rely on Communications::Classifier directly. But if by .Composite structure. the issue is referring to the whole chapter on Composite structure, then it is difficult to understand what the concern is. Various subpackages described in this chapter necessarily rely on the Communications package, such as InvocationActions or Ports, so these packages cannot be used without Behaviors (they inherently involve behavior). As can be seen above, StructuredClasses depends on Communications in two ways: Through Ports and directly. The issue suggests that by deleting the dependency between StructuredClass and Communications due to Communications::Class, one does not depend on Communications. However, one will still have the dependency through Ports. This is for good reasons, as Ports require Communications (they reference Receptions, which are introduced in Communications). I assume that the issue, however, is referring to StructuredClasses::Class. This class is a subtype of Communications::Class and of EncapsulatedClassifier. Again, it relies on the Behavior package, but by design. The reason why Class from communciations is taken is that StructuredClasses::Class should be (i) be able to have ports, i.e., be an encapsulated classifier, and (ii) be able to have behavior, i.e., be a behaviored classifier. Only due to the latter do the additions of ports by inheriting from EncapsulatedClassifier make sense. This allows, for example, to associate interactions as behaviors with the class. The issue states that .composite structure should be usable without behavior.. If .composite structure. refers to the internal structure of a classifier, this is already the case. If .composite structure. refers to a classifier that also has ports, this is not possible, as the definition of ports already refers to behavior. Profiles that want to introduce a new kind of class that can have ports, but no behavior (somewhat nonsensical, but be that as it may), can easily do so. Disposition: Closed, no change Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,cs cb, More Ballot 14 proposed resolutions, 6146 Date: Thu, 13 May 2004 17:11:00 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > 1. Below the relevant package hierarchy for StructuredClasses: > > As you can see, StructuredClasses depends on Communications in > two ways: Through Ports and directly. Why does Ports depend on Communications? Figure 97 doesn't require it. It uses Interfaces, but these are from classes. Vendors who want to implement only structural models should be able to do that. The text on "interaction points" in the sense of message-passing is not necesary to the notion of port. There's alot of text around Ports that refers to interactions. This is too bad, because ports can be purely structural. > The point of structured class is to have a class that (i) has > ports and (ii) is a behaviored classifier. It's the second I disagree with. A structured class can be pure structure. It's only from your application viewpoint that it must be a behaviored classifier. Conrad From: "Thomas Weigert" To: , "uml2ftf" Subject: RE: ,cs cb, More Ballot 14 proposed resolutions, 6146 Date: Thu, 13 May 2004 17:05:15 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Ports depend on Communications as they use Receptions. This is part of the semantics but does not show up in the diagram. Regarding the second point of disagreement, this semantics was what was adopted. We are not to change things that are not broken, do not prevent implementations or profiles, are not unclear, etc. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Thursday, May 13, 2004 4:11 PM > To: uml2ftf > Subject: RE: ,cs cb, More Ballot 14 proposed resolutions, 6146 > > > > Thomas, > > > 1. Below the relevant package hierarchy for StructuredClasses: > > > > As you can see, StructuredClasses depends on Communications in > > two ways: Through Ports and directly. > > Why does Ports depend on Communications? Figure 97 doesn't require it. > It uses Interfaces, but these are from classes. Vendors who want to > implement only structural models should be able to do that. The text on > "interaction points" in the sense of message-passing is not necesary to > the notion of port. > > There's alot of text around Ports that refers to interactions. This is > too bad, because ports can be purely structural. > > > The point of structured class is to have a class that (i) has > > ports and (ii) is a behaviored classifier. > > It's the second I disagree with. A structured class can be pure > structure. It's only from your application viewpoint that it must be a > behaviored classifier. > > Conrad To: "Thomas Weigert" Cc: conrad.bock@nist.gov, "uml2ftf" Subject: RE: ,cs cb, More Ballot 14 proposed resolutions, 6146 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 14 May 2004 08:26:29 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/14/2004 08:26:30, Serialize complete at 05/14/2004 08:26:30 It seems to me that this discussion has reached a state where there are definite differences of opinion about the approach that, under the circumstances, can only be resolved by voting. Therfore, I have decided to include Thomas' resolution to issue 6146 in ballot 14. Regards, Bran "Thomas Weigert" 05/13/2004 06:05 PM To , "uml2ftf" cc Subject RE: ,cs cb, More Ballot 14 proposed resolutions, 6146 Ports depend on Communications as they use Receptions. This is part of the semantics but does not show up in the diagram. Regarding the second point of disagreement, this semantics was what was adopted. We are not to change things that are not broken, do not prevent implementations or profiles, are not unclear, etc. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Thursday, May 13, 2004 4:11 PM > To: uml2ftf > Subject: RE: ,cs cb, More Ballot 14 proposed resolutions, 6146 > > > > Thomas, > > > 1. Below the relevant package hierarchy for StructuredClasses: > > > > As you can see, StructuredClasses depends on Communications in > > two ways: Through Ports and directly. > > Why does Ports depend on Communications? Figure 97 doesn't require it. > It uses Interfaces, but these are from classes. Vendors who want to > implement only structural models should be able to do that. The text on > "interaction points" in the sense of message-passing is not necesary to > the notion of port. > > There's alot of text around Ports that refers to interactions. This is > too bad, because ports can be purely structural. > > > The point of structured class is to have a class that (i) has > > ports and (ii) is a behaviored classifier. > > It's the second I disagree with. A structured class can be pure > structure. It's only from your application viewpoint that it must be a > behaviored classifier. > > Conrad Disposition: Closed, no change