Issue 6149: Activity attributes on Behavior (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: The attributes of Activity defined in CommonBehavior look like they belong on Behavior. Resolution: see above Revised Text: Actions taken: August 30, 2003: received issue March 8, 2005: closed issue Discussion: See resolution of 7319. It introduces OpaqueBehavior for these attributes and removes Activity from Common Behavior. End of Annotations:===== Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Activity attributes on Behavior The attributes of Activity defined in CommonBehavior look like they belong on Behavior Reply-To: From: "Thomas Weigert" To: "Branislav Selic" , Cc: "Thomas Weigert" Subject: Proposed issue resolution for common behavior and composite structure working groups Date: Sat, 29 Nov 2003 19:55:36 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Dear all, please find attached two documents discussing the issues assigned to the common behavior and composite structure working group, respectively. Each document has a summary page indicating the proposed action. Most issues do not require any change, as the UML 2.0 most often has already resolved the issue. There are 2 proposed changes for common behavior and one proposed change for composite structure, all minor. Regarding common behavior there are three issues (6148, 6149, and 6150) which I propose for discussion. While they would not require any change as the solution in the document is as was intended, the issues nevertheless could be addressed: 1. 6148 and 6149 implicitly propose an alternative means of showing textually defined behavior as associated with the Behavior metaclass and making that metaclass concrete. This is as good a solution as the one currently implemented; in my opinion a matter of taste. 2. 6150 requests a notation for method which is reasonable but should be decided upon by teamwork (as nobody ever is satisfied with notation). Please provide feedback on the proposed solution and also provide input to the issues labeled as for discussion. I will propose solutions for those after I have heard from at least several others on the FTF. All the best, Th. Common behavior issues resolution.doc Composite structure issues resolution.doc Discussion: In the current specification, BasicBehavior::Activity is used to specify behavior by its body string (in a given language). Other subclasses of the Behavior metaclass give other mechanisms of specifying the detailed behavior. One could, of course, have put these attributes on Behavior (and made behavior concrete), but this was not what was done. Either solution seems adequate. Note that one would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication) as these two descriptions could be inconsistent. Yet another solution could be to introduce another metaclass, say, TextualBehavior, as a sibling to Activity. Disposition: Discuss together with 6148 OMG Issue No: 6149 Title: Activity attributes on Behavior Source: Kabira Technologies, Inc.NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The attributes of Activity defined in CommonBehavior look like they belong on Behavior. Discussion: In the current specification, BasicBehavior::Activity is used to specify behavior by its body string (in a given language). Other subclasses of the Behavior metaclass give other mechanisms of specifying the detailed behavior. One could, of course, have put these attributes on Behavior (and made behavior concrete), but this was not what was done. Either solution seems adequate. Note that one would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication) as these two descriptions could be inconsistent. Yet another solution could be to introduce another metaclass, say, TextualBehavior, as a sibling to Activity. [Conrad: Seems like all the specialized behaviors would find it useful to have something like body/language attributes to put textual notations for the behaviors. I couldn't find anything in State Machines or Interactions like body/language.] Disposition: Discuss together with 6148 From: "Thomas Weigert" To: Subject: ,cb, Input needed re primitive behaviors Date: Sun, 18 Apr 2004 21:27:32 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Currently, the common behavior model allows the specification of behaviors to be given in simple textual form relying on the metaclass CommonBehaviors::Activity, which has a body attribute that takes a string in a given language (as specified by the language attribute). There are two issues pending pertaining to this topic: 6148 suggests that the abstract metaclass Behavior should be concrete to allow definition of a behavior without committing that this behavior be either a a statemachine, activity, interaction, etc. 6149 suggests that the body and language attributes of CommonBehaviors::Activity be moved to Behavior. If at all, these suggestions should be adopted together. Then one could give a definition of a behavior in some abstract way using Behavior with an associated text string, and later replace it with the concrete behavior. However, there are the following downsides with this solution: 1. The general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. 2. The body and language attributes are inherited to all subtypes of behavior. One would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication but does not) as these two descriptions could be inconsistent. 3. When replacing the abstract behavior with a more concrete one (as suggested in 6148) one still needs to replace one metaclass with another, so nothing was really gained. I think that there are two possible approaches to this problem: A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. I would appreciate input to this topic. To: "Thomas Weigert" Cc: uml2-superstructure-ftf@omg.org Subject: Re: ,cb, Input needed re primitive behaviors X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 19 Apr 2004 08:07:47 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/19/2004 08:07:49, Serialize complete at 04/19/2004 08:07:49 Thomas, My preference is for solution A. It is consistent with the approach we have taken in other places, such as OpaqueExpression. Bran "Thomas Weigert" 04/18/2004 10:27 PM To cc Subject ,cb, Input needed re primitive behaviors Currently, the common behavior model allows the specification of behaviors to be given in simple textual form relying on the metaclass CommonBehaviors::Activity, which has a body attribute that takes a string in a given language (as specified by the language attribute). There are two issues pending pertaining to this topic: 6148 suggests that the abstract metaclass Behavior should be concrete to allow definition of a behavior without committing that this behavior be either a a statemachine, activity, interaction, etc. 6149 suggests that the body and language attributes of CommonBehaviors::Activity be moved to Behavior. If at all, these suggestions should be adopted together. Then one could give a definition of a behavior in some abstract way using Behavior with an associated text string, and later replace it with the concrete behavior. However, there are the following downsides with this solution: 1. The general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. 2. The body and language attributes are inherited to all subtypes of behavior. One would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication but does not) as these two descriptions could be inconsistent. 3. When replacing the abstract behavior with a more concrete one (as suggested in 6148) one still needs to replace one metaclass with another, so nothing was really gained. I think that there are two possible approaches to this problem: A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. I would appreciate input to this topic. From: "Thomas Weigert" To: "Thomas Weigert" , Subject: RE: ,cb, Input needed re primitive behaviors Date: Wed, 21 Apr 2004 07:09:31 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Based on input by Jim A. we should add another option: C. Leave as is, but add a rule in Activity that resolves the conflict when both body string and structure are present. Th. P.S. Resent as I received a delivery error for the omg mail server today for this mail. Please excuse any duplication. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, April 18, 2004 9:28 PM To: uml2-superstructure-ftf@omg.org Subject: ,cb, Input needed re primitive behaviors Currently, the common behavior model allows the specification of behaviors to be given in simple textual form relying on the metaclass CommonBehaviors::Activity, which has a body attribute that takes a string in a given language (as specified by the language attribute). There are two issues pending pertaining to this topic: 6148 suggests that the abstract metaclass Behavior should be concrete to allow definition of a behavior without committing that this behavior be either a a statemachine, activity, interaction, etc. 6149 suggests that the body and language attributes of CommonBehaviors::Activity be moved to Behavior. If at all, these suggestions should be adopted together. Then one could give a definition of a behavior in some abstract way using Behavior with an associated text string, and later replace it with the concrete behavior. However, there are the following downsides with this solution: 1. The general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. 2. The body and language attributes are inherited to all subtypes of behavior. One would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication but does not) as these two descriptions could be inconsistent. 3. When replacing the abstract behavior with a more concrete one (as suggested in 6148) one still needs to replace one metaclass with another, so nothing was really gained. I think that there are two possible approaches to this problem: A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. I would appreciate input to this topic. From: "Thomas Weigert" To: "Thomas Weigert" , Subject: RE: ,cb, Input needed re primitive behaviors Date: Mon, 19 Apr 2004 14:27:33 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Based on input by Jim A. we should add another option: C. Leave as is, but add a rule in Activity that resolves the conflict when both body string and structure are present. Th. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, April 18, 2004 9:28 PM To: uml2-superstructure-ftf@omg.org Subject: ,cb, Input needed re primitive behaviors Currently, the common behavior model allows the specification of behaviors to be given in simple textual form relying on the metaclass CommonBehaviors::Activity, which has a body attribute that takes a string in a given language (as specified by the language attribute). There are two issues pending pertaining to this topic: 6148 suggests that the abstract metaclass Behavior should be concrete to allow definition of a behavior without committing that this behavior be either a a statemachine, activity, interaction, etc. 6149 suggests that the body and language attributes of CommonBehaviors::Activity be moved to Behavior. If at all, these suggestions should be adopted together. Then one could give a definition of a behavior in some abstract way using Behavior with an associated text string, and later replace it with the concrete behavior. However, there are the following downsides with this solution: 1. The general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. 2. The body and language attributes are inherited to all subtypes of behavior. One would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication but does not) as these two descriptions could be inconsistent. 3. When replacing the abstract behavior with a more concrete one (as suggested in 6148) one still needs to replace one metaclass with another, so nothing was really gained. I think that there are two possible approaches to this problem: A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. I would appreciate input to this topic. From: "Thomas Weigert" To: Subject: ,cb, Input needed re primitive behaviors Date: Wed, 28 Apr 2004 12:52:19 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Dear all, this request for input was sent earlier and I have received three inputs so far: one supporting option A, one B, and one C. Please provide your input so that I can resolve these issues in a manner that is satisfactory to most. Thanks, Th. Currently, the common behavior model allows the specification of behaviors to be given in simple textual form relying on the metaclass CommonBehaviors::Activity, which has a body attribute that takes a string in a given language (as specified by the language attribute). There are two issues pending pertaining to this topic: 6148 suggests that the abstract metaclass Behavior should be concrete to allow definition of a behavior without committing that this behavior be either a a statemachine, activity, interaction, etc. 6149 suggests that the body and language attributes of CommonBehaviors::Activity be moved to Behavior. If at all, these suggestions should be adopted together. Then one could give a definition of a behavior in some abstract way using Behavior with an associated text string, and later replace it with the concrete behavior. However, there are the following downsides with this solution: 1. The general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. 2. The body and language attributes are inherited to all subtypes of behavior. One would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication but does not) as these two descriptions could be inconsistent. 3. When replacing the abstract behavior with a more concrete one (as suggested in 6148) one still needs to replace one metaclass with another, so nothing was really gained. I think that there are two possible approaches to this problem: A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. C. Leave current situation, but fix Activities::Activity to explain what happens if both types of behavior descriptions are present and inconsistent. I would appreciate input to this topic. From: "Thomas Weigert" To: Subject: ,cb, Input needed re primitive behaviors Date: Wed, 12 May 2004 00:01:47 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Dear all, last chance to comment before I resolve this issue. I have received four inputs so far: two supporting option A, one B, and one C. Thanks, Th. Currently, the common behavior model allows the specification of behaviors to be given in simple textual form relying on the metaclass CommonBehaviors::Activity, which has a body attribute that takes a string in a given language (as specified by the language attribute). There are two issues pending pertaining to this topic: 6148 suggests that the abstract metaclass Behavior should be concrete to allow definition of a behavior without committing that this behavior be either a a statemachine, activity, interaction, etc. 6149 suggests that the body and language attributes of CommonBehaviors::Activity be moved to Behavior. If at all, these suggestions should be adopted together. Then one could give a definition of a behavior in some abstract way using Behavior with an associated text string, and later replace it with the concrete behavior. However, there are the following downsides with this solution: 1. The general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. 2. The body and language attributes are inherited to all subtypes of behavior. One would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication but does not) as these two descriptions could be inconsistent. 3. When replacing the abstract behavior with a more concrete one (as suggested in 6148) one still needs to replace one metaclass with another, so nothing was really gained. I think that there are two possible approaches to this problem: A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. C. Leave current situation, but fix Activities::Activity to explain what happens if both types of behavior descriptions are present and inconsistent. I would appreciate input to this topic. OMG Issue No: 6149 Title: Activity attributes on Behavior Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The attributes of Activity defined in CommonBehavior look like they belong on Behavior. Discussion: In the current specification, BasicBehavior::Activity is used to specify behavior by its body string (in a given language). Other subclasses of the Behavior metaclass give other mechanisms of specifying the detailed behavior. This, of course, also leads to the question as to what happens if both a body string and a structural explication is given in Activities::Activity as these two descriptions could be inconsistent. Such explication has been forgotten in the activities chapter of the current specification. Note that this issue is also closely related to issue 6148. There are at least three possible solutions to address this concern: A. Introduce an additional metaclass which captures what CommonBehavior::Activities does (give a description of behavior in simple textual form) without inviting the confusion with Activities::Activity. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. C. Leave current situation, but fix Activities::Activity to explain what happens if both types of behavior descriptions are present and inconsistent. The solution adopted is, after discussion in the FTF, was (A) for the reason that this solves the problem, does not invite the current confusion with Activities::Activity, and is most consistent with what has been done in other areas of the specification: For example, OpaqueExpression defines a value that is given in simple textual form only, while other concrete subtypes of value specification give structural detail. The name suggested, OpaqueBehavior, is chosen in analogy to the situation with value specification. While this name is awkward, consistency with the rest of the specification dictates this name. 1. In the CommonBehavior chapter, rename Activity to OpaqueBehavior. Replace every occurrence of .Activity. or .activity. in section 13.3.1 of ptc/03-08-02 by .OpaqueBehavior. or .opaque behavior., respectively. Then move this section before the section on OpaqueExpression. 2. Replace the metaclass Activity in Figure 312 by OpaqueBehavior. 3. In the introductory section, on p.370, replace in the fourth line the phrase .Petri-net like graphs (.Activity (from BasicBehaviors). on page 378). by .Petri-net like graphs (.Activity (from Activities). on page 265).. Disposition: Resolved To: "Thomas Weigert" Cc: "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: ,cs cb, More Ballot 14 proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 14 May 2004 08:24:41 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/14/2004 08:24:44, Serialize complete at 05/14/2004 08:24:44 Thomas, I see at least two technical problems with your resolution to issue 6149: You have not specified what happens to the two attributes of Activity in the original definition in BasicBehaviors ("body" and "language"). Should these now be redefined in Activity, or moved up to Behavior? If BasicBehaviors::Activity is removed, something needs to be done with the model in Figure 176, which references it. As it stands, your resolution leaves the model in an obviously inconsistent state. In addition -- given that (a) this is the first time that the resolution is provided in its full form and (b) that it introduces something new into UML -- the change seems significant enough to warrant a further soaking. You have certainly done the right thing by polling people on the resolution approach first -- I wish more people would do it this way. Therefore, I will not include 6149 and 6148 (which is related to it) into Ballot 14. However, I feel that it must be included in ballot 15. So, let's see Bran "Thomas Weigert" 05/13/2004 01:02 AM To "Thomas Weigert" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: ,cs cb, More Ballot 14 proposed resolutions Attached please find the next installment of resolutions in this group. I have added 6148: This is resolved by 6149 6149: After pondering the feedback I believe the best solution is to solve this consistently with how the same situation is handled in ValueSpecification. Added additional detail to 6146 to answer Conrad's question. In 6251, I added a proposed slightly more readable constraint [4]. I would like to propose this but probably this minor change is warranted only if we had OCL as well to make it worthwhile. Th. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, May 11, 2004 11:56 PM To: Thomas Weigert; Branislav Selic; uml2-superstructure-ftf@omg.org Subject: ,cs cb, More Ballot 14 proposed resolutions Attached find the updated set of issue resolutions. The added issues should be uncontroversial. 6154: I fixed the problem as described by Conrad. I also removed the reference to write-once attributes that Bran was sensitive to (albeit it was not contained in the issue itself). 6185: Corrected this issue as suggested. 6231: The problem was actually slightly different than the issue noticed, but either way it is fixed. Th. -----Original Message----- From: Thomas Weigert [mailto:Thomas.Weigert@motorola.com] Sent: Tuesday, May 04, 2004 3:28 PM To: Thomas Weigert; Branislav Selic; uml2-superstructure-ftf@omg.org Subject: ,cs cb, Ballot 14 proposed resolutions 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. [attachment "Comp struc + com beh issues 14 v3 done.doc" deleted by Branislav Selic/Ottawa/IBM] From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: "Thomas Weigert" , Subject: RE: ,cs cb, More Ballot 14 proposed resolutions Date: Fri, 14 May 2004 07:34:13 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Regarding your first bullet, it is covered by saying that CommonBehavior::Activities is replaced by the newly introduced metaclass. There is no CommonBehavior::Activities, consequentially, but I could state that explicitly if you prefer. Regarding the second bullet: Yes I am aware of that. I had assumed that by implication that would switch over to the newly introduced class (replacement seems a logical operation). Note that I have filed in issue to address this. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, May 14, 2004 7:25 AM To: Thomas Weigert Cc: Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cs cb, More Ballot 14 proposed resolutions Thomas, I see at least two technical problems with your resolution to issue 6149: You have not specified what happens to the two attributes of Activity in the original definition in BasicBehaviors ("body" and "language"). Should these now be redefined in Activity, or moved up to Behavior? If BasicBehaviors::Activity is removed, something needs to be done with the model in Figure 176, which references it. As it stands, your resolution leaves the model in an obviously inconsistent state. In addition -- given that (a) this is the first time that the resolution is provided in its full form and (b) that it introduces something new into UML -- the change seems significant enough to warrant a further soaking. You have certainly done the right thing by polling people on the resolution approach first -- I wish more people would do it this way. Therefore, I will not include 6149 and 6148 (which is related to it) into Ballot 14. However, I feel that it must be included in ballot 15. So, let's see To: "Thomas Weigert" Cc: "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: ,cs cb, More Ballot 14 proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 14 May 2004 08:59:07 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/14/2004 08:59:08, Serialize complete at 05/14/2004 08:59:08 Thomas, I would prefer if we left it for ballot 15 not only because introducing a new resolution at this point (it may not even have an official OMG number yet) is cutting the soak time to almost zero, but also because of the substantive change introduced by your fix. It will give FTF members more time to ponder the consequences. Even though you did poll the FTF (and got only a few responses), I think that not everyone understood those consequences from the discussion that took place. Cheers, Bran "Thomas Weigert" 05/14/2004 08:34 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc "Thomas Weigert" , Subject RE: ,cs cb, More Ballot 14 proposed resolutions Regarding your first bullet, it is covered by saying that CommonBehavior::Activities is replaced by the newly introduced metaclass. There is no CommonBehavior::Activities, consequentially, but I could state that explicitly if you prefer. Regarding the second bullet: Yes I am aware of that. I had assumed that by implication that would switch over to the newly introduced class (replacement seems a logical operation). Note that I have filed in issue to address this. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, May 14, 2004 7:25 AM To: Thomas Weigert Cc: Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cs cb, More Ballot 14 proposed resolutions Thomas, I see at least two technical problems with your resolution to issue 6149: You have not specified what happens to the two attributes of Activity in the original definition in BasicBehaviors ("body" and "language"). Should these now be redefined in Activity, or moved up to Behavior? If BasicBehaviors::Activity is removed, something needs to be done with the model in Figure 176, which references it. As it stands, your resolution leaves the model in an obviously inconsistent state. In addition -- given that (a) this is the first time that the resolution is provided in its full form and (b) that it introduces something new into UML -- the change seems significant enough to warrant a further soaking. You have certainly done the right thing by polling people on the resolution approach first -- I wish more people would do it this way. Therefore, I will not include 6149 and 6148 (which is related to it) into Ballot 14. However, I feel that it must be included in ballot 15. So, let's see Reply-To: From: "Conrad Bock" To: Subject: RE: ,cs cb, More Ballot 14 proposed resolutions, 6149 Date: Fri, 14 May 2004 15:04:58 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Thomas, > I would prefer if we left it for ballot 15 not only because > introducing a new resolution at this point Issues 6149 can also have negative consequences for state machines when taken alone. If Activity no longer has a body/language, state machines will not have a way to specify an uninterpreted activity. It needs to be resolved along with Issue 7335: behaviors, which asks that state machine reference Behavior instead of Activity. OMG Issue No: 6149 Title: Activity attributes on Behavior Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The attributes of Activity defined in CommonBehavior look like they belong on Behavior. Discussion: In the current specification, BasicBehavior::Activity is used to specify behavior by its body string (in a given language). Other subclasses of the Behavior metaclass give other mechanisms of specifying the detailed behavior. This, of course, also leads to the question as to what happens if both a body string and a structural explication is given in Activities::Activity as these two descriptions could be inconsistent. Such explication has been forgotten in the activities chapter of the current specification. Note that this issue is also closely related to issue 6148. There are at least three possible solutions to address this concern: A. Introduce an additional metaclass which captures what CommonBehavior::Activities does (give a description of behavior in simple textual form) without inviting the confusion with Activities::Activity. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. C. Leave current situation, but fix Activities::Activity to explain what happens if both types of behavior descriptions are present and inconsistent. The solution adopted is, after discussion in the FTF, was (A) for the reason that this solves the problem, does not invite the current confusion with Activities::Activity, and is most consistent with what has been done in other areas of the specification: For example, OpaqueExpression defines a value that is given in simple textual form only, while other concrete subtypes of value specification give structural detail. The name suggested, OpaqueBehavior, is chosen in analogy to the situation with value specification. While this name is awkward, consistency with the rest of the specification dictates this name. 1. In the CommonBehavior chapter, rename Activity to OpaqueBehavior. Replace every occurrence of .Activity. or .activity. in section 13.3.1 of ptc/03-08-02 by .OpaqueBehavior. or .opaque behavior., respectively. Then move this section before the section on OpaqueExpression. 2. Replace the metaclass Activity in Figure 312 by OpaqueBehavior. 3. In the introductory section, on p.370, replace in the fourth line the phrase .Petri-net like graphs (.Activity (from BasicBehaviors). on page 378). by .Petri-net like graphs (.Activity (from Activities). on page 265).. 4. Correspondingly, replace the occurrences of .Activity. and .activity., or their plural forms, by .OpaqueBehavior., .opaque behavior., or their plural forms, respectively. Note that a recent issue 7335 suggests to replace this by .Behavior. instead, but in the meantime, this change is consistent with the original intentions of the submission. From: Eran Gery To: Thomas Weigert Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,cb cs, Proposed issues for 15 Date: Wed, 19 May 2004 19:01:41 +0300 X-Mailer: Internet Mail Service (5.5.2656.59) Thomas 6149 by itself invalidates state machines, as they can no longer instantiate "opaque" behaviors. I will propose in my resubmission of 6381 (the one with the action notation) that statemachines transitions will reference behavior(s). You should mention in 6149 that it refers to 6381. I will also mention 6149 in 6381. Eran -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, May 16, 2004 9:30 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: ,cb cs, Proposed issues for 15 Dear all, attached please find a set of proposed issues for Ballot 15. I would like to draw special attention to 6373. This issue resolution also affects the infrastructure, so a corresponding resolution (with different wording, as the changes would be spread over several packages) has to be floated there. An issue that highlights the problem in the infrastructure has been submitted. Please provide feedback to improve these resolutions. Thanks, Th. From: "Thomas Weigert" To: "Eran Gery" , "Thomas Weigert" Cc: Subject: RE: ,cb cs, Proposed issues for 15 Date: Wed, 19 May 2004 11:09:56 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) I have already submitted such an issue... Th. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: Wednesday, May 19, 2004 11:02 AM To: Thomas Weigert Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,cb cs, Proposed issues for 15 Thomas 6149 by itself invalidates state machines, as they can no longer instantiate "opaque" behaviors. I will propose in my resubmission of 6381 (the one with the action notation) that statemachines transitions will reference behavior(s). You should mention in 6149 that it refers to 6381. I will also mention 6149 in 6381. Eran -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, May 16, 2004 9:30 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: ,cb cs, Proposed issues for 15 Dear all, attached please find a set of proposed issues for Ballot 15. I would like to draw special attention to 6373. This issue resolution also affects the infrastructure, so a corresponding resolution (with different wording, as the changes would be spread over several packages) has to be floated there. An issue that highlights the problem in the infrastructure has been submitted. Please provide feedback to improve these resolutions. Thanks, Th. Disposition: Resolved Reply-To: From: "Conrad Bock" To: Cc: Subject: RE: ,cb cs, Proposed issues for 15 Date: Wed, 26 May 2004 13:12:08 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, Eran, Bran, A comment on Thomas' proposals for ballot 15 below. 6149 is dependent on the resolution of 7335 in state machines. Conrad - 6149: Activity attributes on Behavior This must be resolved with Issue 7335 (behaviors), which asks for state machines to refer to behaviors instead of activities. The resolution requires a change in activities; In Figure 176, Replace Activity (from BasicBehaviors) with Behavior (From BasicBehaviors). Can you add that? From: "Thomas Weigert" To: , Subject: RE: ,cb cs, Proposed issues for 15 Date: Wed, 26 May 2004 14:31:13 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Thanks, will do... Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Wednesday, May 26, 2004 12:12 PM > To: uml2-superstructure-ftf@omg.org > Cc: mu2i-ftf@omg.org > Subject: RE: ,cb cs, Proposed issues for 15 > > > > Hi Thomas, Eran, Bran, > > A comment on Thomas' proposals for ballot 15 below. 6149 is dependent > on the resolution of 7335 in state machines. > > Conrad > > > - 6149: Activity attributes on Behavior > > This must be resolved with Issue 7335 (behaviors), which asks for > state machines to refer to behaviors instead of activities. > > > The resolution requires a change in activities; > > In Figure 176, Replace Activity (from BasicBehaviors) with > Behavior (From BasicBehaviors). > > Can you add that? From: "Thomas Weigert" To: "Branislav Selic" , Subject: RE: Current draft of ballot 15 Date: Thu, 27 May 2004 21:58:55 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, per Conrad's request, please add the following line to end of the resolution of 6149: 5. In Figure 176 .Nodes., p.268, replace the metaclass Activity (from BasicBehaviors) with Behavior (from BasicBehaviors). As discussed today, in 6356 please remove the sentence: In section 9.3.11. .Port. of ptc/03-08-02, on p.168 add in the associations section: Otherwise, everything looks good. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, May 27, 2004 5:51 PM To: uml2-superstructure-ftf@omg.org Subject: Current draft of ballot 15 Please review and provide feedback. It is highly likely that I may be out of e-mail contact after tomorrow morning, so this may become the official ballot. If there are issues that need to be fixed, they will be pulled from the ballot later. Regards, Bran Reply-To: From: "Conrad Bock" To: , , Subject: RE: Ballot 15, addiitonal comment on 6149 Date: Fri, 28 May 2004 15:09:43 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, Bran, Additional comment on 6149 (other than it should be pulled from the ballot): It should remove the <> dependency between BasicActivities and BasicBehaviors in Figure 175. That was there just to merge BasicActivities::Activity with BasicBehaviors:Activity. Conrad From: "Thomas Weigert" To: , Subject: RE: Ballot 15, addiitonal comment on 6149 Date: Sat, 29 May 2004 08:43:12 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, it is fine with me to postpone 6149 until the resolution of 7335 but you decide (I think we can go either way). Why don't you assign 7335 to me and I take care of it for the next ballot? Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Friday, May 28, 2004 2:10 PM > To: uml2-superstructure-ftf@omg.org; ocl2-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: Ballot 15, addiitonal comment on 6149 > > > > Thomas, Bran, > > Additional comment on 6149 (other than it should be pulled from the > ballot): > > It should remove the <> dependency between BasicActivities and > BasicBehaviors in Figure 175. That was there just to merge > BasicActivities::Activity with BasicBehaviors:Activity. > > Conrad To: issues@omg.org, mu2i-ftf@omg.org Subject: [mu2i-ftf] Issue for EMOF in UML 2 Infrastructure/MOF 2 FTF X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Stephen Brodsky Date: Fri, 11 Jun 2004 14:27:40 -0700 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 6.0.2CF2HF342 | June 4, 2004) at 06/11/2004 15:27:44, Serialize complete at 06/11/2004 15:27:44 Issue for UML 2 Infrastructure/MOF 2 FTF The EMOF model should contain a tag on EMOF:Element of XMI ContentType with value "any". See the discussion and resolution of MOF 2 XMI FTF issue 6345 for background. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 From: "Thomas Weigert" To: , Subject: RE: Ballot 15, addiitonal comment on 6149 Date: Sat, 29 May 2004 08:43:12 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, it is fine with me to postpone 6149 until the resolution of 7335 but you decide (I think we can go either way). Why don't you assign 7335 to me and I take care of it for the next ballot? Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Friday, May 28, 2004 2:10 PM > To: uml2-superstructure-ftf@omg.org; ocl2-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: Ballot 15, addiitonal comment on 6149 > > > > Thomas, Bran, > > Additional comment on 6149 (other than it should be pulled from the > ballot): > > It should remove the <> dependency between BasicActivities and > BasicBehaviors in Figure 175. That was there just to merge > BasicActivities::Activity with BasicBehaviors:Activity. > > Conrad > From: Eran Gery To: Branislav Selic , Thomas Weigert Cc: conrad.bock@nist.gov, uml2-superstructure-ftf@omg.org Subject: RE: Ballot 15, addiitonal comment on 6149 Date: Tue, 1 Jun 2004 17:41:30 +0300 X-Mailer: Internet Mail Service (5.5.2656.59) Bran I will be travelling to the US tomorrow morning. I'm ok with Thomas' proposal to have a resolution for 7335, based on what he proposed in 7335. I will have to rely on this to resolve 6381. Note I plan to change the multiplicity between transition to behavior to * to accomodate a sequence of behaviors, so it will be more efficient to do it in 7335. But if not I will do in 6381. Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, June 01, 2004 11:57 AM To: Thomas Weigert Cc: conrad.bock@nist.gov; uml2-superstructure-ftf@omg.org Subject: RE: Ballot 15, addiitonal comment on 6149 Apologies to all for being unresponsive on this. We can discuss this issue during our regular Wednesday telecon tomorrow. Regards, Bran "Thomas Weigert" 05/29/2004 09:43 AM To , cc Subject RE: Ballot 15, addiitonal comment on 6149 Bran, it is fine with me to postpone 6149 until the resolution of 7335 but you decide (I think we can go either way). Why don't you assign 7335 to me and I take care of it for the next ballot? Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Friday, May 28, 2004 2:10 PM > To: uml2-superstructure-ftf@omg.org; ocl2-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: Ballot 15, addiitonal comment on 6149 > > > > Thomas, Bran, > > Additional comment on 6149 (other than it should be pulled from the > ballot): > > It should remove the <> dependency between BasicActivities and > BasicBehaviors in Figure 175. That was there just to merge > BasicActivities::Activity with BasicBehaviors:Activity. > > Conrad > Subject: RE: Ballot 15 Date: Tue, 1 Jun 2004 09:00:44 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 15 Thread-Index: AcREtzTuOl+HL7KNSjayTEupf9SvaQDOT/fw From: "Pidcock, Woody" To: Cc: , , X-OriginalArrivalTime: 01 Jun 2004 16:00:44.0875 (UTC) FILETIME=[98C1E1B0:01C447F1] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i51G4Nun002602 Conrad, I am not familiar with the details. Can you answer a "lurker's" question regarding this? Is there a notion in UML for OpaqueExpressions or other expressions accessible to State/Event models, similar to what we had in CDIF, where this is handled with two attributes: one the uninterpreted text block, the other a value from an enumerated list indicating the language used to encode the uninterpreted text block? -Woody -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Friday, May 28, 2004 6:24 AM To: uml2-superstructure-ftf@omg.org; ocl2-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Ballot 15 Bran, Thomas, Eran, As I mentioned several times, the ballot as it stands will prevent state machines from using uninterpreted strings on states and transitions. The resolution to 6149 moves the body language strings to OpaqueExpression, where states and transitions have no access to them, because states and transtions refer to activities. Please remove 6149 from the ballot until this is resolved, in particular by 7335 in state machines. Conrad Subject: RE: Ballot 15 Date: Tue, 1 Jun 2004 16:52:13 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 15 Thread-Index: AcREtzTuOl+HL7KNSjayTEupf9SvaQDOT/fwAApBJfA= From: "Karl Frank" To: "Pidcock, Woody" , Cc: , , X-OriginalArrivalTime: 01 Jun 2004 20:52:14.0270 (UTC) FILETIME=[513FC5E0:01C4481A] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i51Kupun008107 Opaque Expression has an optional string-valued language attribute. I advocated for a standard list of language ID strings but this was rejected. What we have is "OCL" understood for the current version of OCL, whatever that may be, and an assumption that there is in the language community a standard name. The FAS spec covers this in section 7.5.2, which says amongst other things, under style guidelines, "A language name should be spelled and capitalized exactly as it appears in the document defining the language." - Karl Frank Borland Software Corp. -----Original Message----- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Tuesday, 01 June, 2004 12:01 PM To: conrad.bock@nist.gov Cc: uml2-superstructure-ftf@omg.org; ocl2-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Ballot 15 Conrad, I am not familiar with the details. Can you answer a "lurker's" question regarding this? Is there a notion in UML for OpaqueExpressions or other expressions accessible to State/Event models, similar to what we had in CDIF, where this is handled with two attributes: one the uninterpreted text block, the other a value from an enumerated list indicating the language used to encode the uninterpreted text block? -Woody -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Friday, May 28, 2004 6:24 AM To: uml2-superstructure-ftf@omg.org; ocl2-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Ballot 15 Bran, Thomas, Eran, As I mentioned several times, the ballot as it stands will prevent state machines from using uninterpreted strings on states and transitions. The resolution to 6149 moves the body language strings to OpaqueExpression, where states and transitions have no access to them, because states and transtions refer to activities. Please remove 6149 from the ballot until this is resolved, in particular by 7335 in state machines.