Issue 6491: Outputting constants (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: How are constants introduced in a flow, eg, to output a constant to an activity parameter node? UML 1.5 had GetLiteralAction to output a constant. Reintroduce it or some construct that has the same effect. Resolution: see above Revised Text: Actions taken: November 7, 2003: received issue March 8, 2005: closed issue Discussion: ValuePin is a kind of InputPin that provides inputs to actions based on value specifications. It has the following problems: ValuePin cannot provide values for output activity parameter nodes. In particular, it cannot be used to dynamically choose what value specification to output to an activity paramater nodes, for example, with a decision node (see example below). ValuePin is is not flexible in when it is evaluated. It can only be evaluated as an input to an action when the other inputs are already available. A number of alternatives have been suggested: ?? Use a ValuePin with a CallBehaviorAction to a dummy behavior that outputs the same value that is input to it. Most users find dummy behaviors too cumbersome. ?? Use a value specification as a default value for an output parameter. This does not address either of the above problems with ValuePin, since they cannot be used for dynamically chosen values (see example below). ?? Use ConditionalAction with input value pins that each flow to an output pin on only one the conditional branches. This is even more cumbersome than dummy behaviors. Consequently, the current metamodel is not backwardly compatible with UML 1.5 LiteralAction. Add an action for evaluating a value specification as described below. In Figure 144, add ValueSpecificationAction, as shown (with change from 6222, and consolidated layout In Actions chapter, insert new entry for ValueSpecificationAction alphabetically as follows: ValueSpecificationAction ValueSpecificationAction is an action that evaluates a value specification. Description This action returns the result of evaluating a value specification. Attributes None. Associations value : ValueSpecification [1..1] (Specialized from Action:output) Value specification to be evaluated. Constraints [1] The type of value specification must be compatible with the type of the result pin. [2] The multiplicity of the result pin is 1..1. ReadSelfAction OutputPin (from BasicActivities) Classifier (from Kernel) CreateObjectAction 1 0..1 +result {subsets output} 1 * +classifier Action (from BasicActivities) InputPin (from BasicActivities) DestroyObjectAction isDestroyLinks : Boolean = false isDestroyOwnedObjects : Boolean = false 1 0..1 +target {subsets input} InputPin (from BasicActivities) TestIdentityAction 1 0..1 +first {subsets input} 1 0..1 +second {subsets input} ValueSpecification (from Kernel) ValueSpecificationAction 1 0..1 +value OutputPin (from BasicActivities) 1 0..1 +result {subsets output} 1 0..1 +result {subsets output} 1 0..1 +result {subsets output} Semantics The value specification is evaluated when the action is enabled. Notation The action is labelled with the value specification, as shown below. Figure – ValueSpecificationAction notation Examples The figure below shows a value specification action used to output a constant from an activity. Figure – Example ValueSpecificationAction Rationale ValueSpecificationAction is introduced for injecting constants and other value specifications into activity flow. Changes from previous UML ValueSpecificationAction replaces LiteralValueAction from UML 1.5. value specification 5 Integer 6 End of Annotations:===== me: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Outputting constants How are constants introduced in a flow, eg, to output a constant to an activity parameter node? UML 1.5 had GetLiteralAction to output a constant. Reintroduce it or some construct that has the same effect. OMG Issue No: 6491 Title: Outputting constants Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: How are constants introduced in a flow, eg, to output a constant to an activity parameter node? UML 1.5 had GetLiteralAction to output a constant. Reintroduce it or some construct that has the same effect. Discussion: ValuePin can only be used to input values to an action, and is not flexible in when it is evaluated. Add an action for evaluating a value specification as described below. In Figure 144, add ValueSpecificationAction, as shown (with change from 6222, and consolidated layout): In Actions chapter, insert new entry for ValueSpecificationAction alphabetically as follows: ValueSpecificationAction ValueSpecificationAction is an action that evaluates a value specification. Description This action returns the result of evaluating a value specification. Attributes None. Associations value : ValueSpecification [1..1] (Specialized from Action:output) Value specification to be evaluated. Constraints [1] The type of value specification must be compatible with the type of the result pin. Semantics The value specification is evaluated when the action is enabled. Notation The action is labelled with the value specification, as shown below. Figure . ValueSpecificationAction notation Examples The figure below shows a value specification action used to output a constant from an activity. Figure . Example ValueSpecificationAction Rationale ValueSpecificationAction is introduced for injecting constants and other value specifications into activity flow. Changes from previous UML ValueSpecificationAction replaces LiteralValueAction from UML 1.5. Disposition: Resolved :wq Subject: changing vote on 6491 Date: Tue, 6 Apr 2004 12:46:24 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Official Ballot 11 -- Please vote Thread-Index: AcQb9F8sYYHt9gM3QzyS6MqlZd4kcgAAVuGf From: "Karl Frank" To: "Thomas Weigert" , "Thomas Weigert" , "Branislav Selic" , , X-OriginalArrivalTime: 06 Apr 2004 16:46:25.0505 (UTC) FILETIME=[B32AD510:01C41BF6] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i36GnKAQ002699 After reviewing the issue and the proposal, Borland agrees that it would be wise to allow more time to discuss 6491. Borland changes its prior YES on 6491 to abstain. I suggest others also review 6491 carefully and consider that the specific subclasses of action are already very complicated and that we should hesistate to add more without compelling reasons. - Karl Frank Borland Software -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tue 4/6/2004 10:24 AM To: Thomas Weigert; Branislav Selic; uml2-superstructure-ftf@omg.org; conrad.bock@nist.gov Cc: Subject: RE: Official Ballot 11 -- Please vote Dear all, I have since learned that Conrad is on vacation this week. As this does not give him any opportunity to work on this issue or to clarify the problem I would request that those of you who already voted on this issue to change your vote so that we can move this issue resolution onto the next ballot. I believe it is better to have a discussion on this issue than cramming it through right now. As it stands, I believe that this issue resolution proposes a duplicate functionality. If we were to adopt this proposal, we should delete ValuePin as it would be superfluous. There would still be further duplication with the parameter values, but that would be unavoidable. However, the simplest is to not introduce this new action. The reason why I am so concerned about this duplication is that in my experience it invites incompatibilities, as one vendor is likely to implement one way, while another vendor might implement the other way, and the models become not interchangeable. By changing your vote you are not condemning this issue yet, but allow for more time to discuss. As you know, the first time we have all seen these solutions was this weekend. All the best, Th. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, April 06, 2004 6:41 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; Conrad Bock [conrad.bock@nist.gov] Subject: RE: Official Ballot 11 -- Please vote Dear all, I have concerns about the resolution to 6491. The special input pin ValuePin was introduced to yield values that can flow into actions. To indicate constants on parameters one uses the value specification associated as default value. This will also cover ActivityParameterNodes through the associated Parameter. Therefore, the example given in the resolution would be modeled by the value specification representing "5" as being the default value of the parameter that is associated with the ActivityParameterNode. There is no need, at least in this example, for any new action. Now there may be need for a notation to designate this situation, but that is a different story. I would assume that the value specification associated with the parameter would be shown somehow inside the box representing the parameter node. Anyway, please reconsider this proposal in light of the above. At minimum, there should be a reason given why the available solution in the current spec is not used. Thanks, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, April 02, 2004 4:24 PM To: uml2-superstructure-ftf@omg.org Cc: ocl2-ftf@omg.org; mu2i-ftf@omg.org Subject: Official Ballot 11 -- Please vote Attached is the official Ballot 11. I apologize for the size, but it includes an embedded convenience file related to the proposed resolution to issue 7159. I cannot zip it because it will get bounced by the OMG server. From: "Thomas Weigert" To: "Branislav Selic" , , Subject: RE: Official Ballot 11 -- Please vote Date: Tue, 6 Apr 2004 06:40:55 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Dear all, I have concerns about the resolution to 6491. The special input pin ValuePin was introduced to yield values that can flow into actions. To indicate constants on parameters one uses the value specification associated as default value. This will also cover ActivityParameterNodes through the associated Parameter. Therefore, the example given in the resolution would be modeled by the value specification representing "5" as being the default value of the parameter that is associated with the ActivityParameterNode. There is no need, at least in this example, for any new action. Now there may be need for a notation to designate this situation, but that is a different story. I would assume that the value specification associated with the parameter would be shown somehow inside the box representing the parameter node. Anyway, please reconsider this proposal in light of the above. At minimum, there should be a reason given why the available solution in the current spec is not used. Thanks, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, April 02, 2004 4:24 PM To: uml2-superstructure-ftf@omg.org Cc: ocl2-ftf@omg.org; mu2i-ftf@omg.org Subject: Official Ballot 11 -- Please vote Attached is the official Ballot 11. I apologize for the size, but it includes an embedded convenience file related to the proposed resolution to issue 7159. I cannot zip it because it will get bounced by the OMG server. From: "Thomas Weigert" To: "Thomas Weigert" , "Branislav Selic" , , Subject: RE: Official Ballot 11 -- Please vote Date: Tue, 6 Apr 2004 09:24:20 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Dear all, I have since learned that Conrad is on vacation this week. As this does not give him any opportunity to work on this issue or to clarify the problem I would request that those of you who already voted on this issue to change your vote so that we can move this issue resolution onto the next ballot. I believe it is better to have a discussion on this issue than cramming it through right now. As it stands, I believe that this issue resolution proposes a duplicate functionality. If we were to adopt this proposal, we should delete ValuePin as it would be superfluous. There would still be further duplication with the parameter values, but that would be unavoidable. However, the simplest is to not introduce this new action. The reason why I am so concerned about this duplication is that in my experience it invites incompatibilities, as one vendor is likely to implement one way, while another vendor might implement the other way, and the models become not interchangeable. By changing your vote you are not condemning this issue yet, but allow for more time to discuss. As you know, the first time we have all seen these solutions was this weekend. All the best, Th. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, April 06, 2004 6:41 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; Conrad Bock [conrad.bock@nist.gov] Subject: RE: Official Ballot 11 -- Please vote Dear all, I have concerns about the resolution to 6491. The special input pin ValuePin was introduced to yield values that can flow into actions. To indicate constants on parameters one uses the value specification associated as default value. This will also cover ActivityParameterNodes through the associated Parameter. Therefore, the example given in the resolution would be modeled by the value specification representing "5" as being the default value of the parameter that is associated with the ActivityParameterNode. There is no need, at least in this example, for any new action. Now there may be need for a notation to designate this situation, but that is a different story. I would assume that the value specification associated with the parameter would be shown somehow inside the box representing the parameter node. Anyway, please reconsider this proposal in light of the above. At minimum, there should be a reason given why the available solution in the current spec is not used. Thanks, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, April 02, 2004 4:24 PM To: uml2-superstructure-ftf@omg.org Cc: ocl2-ftf@omg.org; mu2i-ftf@omg.org Subject: Official Ballot 11 -- Please vote Attached is the official Ballot 11. I apologize for the size, but it includes an embedded convenience file related to the proposed resolution to issue 7159. I cannot zip it because it will get bounced by the OMG server. To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org, ocl2-ftf@omg.org Subject: Proposed change of closing date for Ballot 11 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sun, 11 Apr 2004 10:00:36 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/11/2004 10:00:40, Serialize complete at 04/11/2004 10:00:40 In last week's telecon, I proposed to postpone the closing date for Ballot 11 from Wednesday, April 14, to Friday, April 16. This is because there are some concerns about issue 6491 raised by Thomas. He was concerned enough to appeal to those who have already voted on Ballot 11 to reconsider their vote on 6491. Unfortunately, Conrad, who proposed the resolution was away on vacation and did not have time to respond to Thomas' concerns. By postponing things this way, I hope that at least the different positions can be clarified. So, unless someone objects in the next several days, I will assume that there is consensus to postpone the closing time for Ballot 11 as specified above. However, I would like to appeal to you to make sure that you review proposed resolutions BEFORE a ballot becomes official so that we can avoid such exceptional situations. I do not plan for such delays to become part of the regular process in future ballots. (The only reason that I suggested above was because of the unusual circumstance that Conrad was unable to defend his proposal on time due to the circumstances of the Easter holidays.) Regards, Bran From: "Thomas Weigert" To: , Subject: RE: Official Ballot 11 -- Please vote Date: Tue, 13 Apr 2004 16:03:48 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Dear all, based on Conrad's input below we can close issue 6491 without change: The issue asks how to output constants to an activity parameter node. As Conrad comments below, the current UML specification already allows constants to be output. In fact, any ValueSpecification, as requested by your enlarged problem below, can be output using the mechanism described by me earlier. I believe you agree with that. Thus the issue raised in 6491 is completely covered by the existing specification. Consequentially, the resolution proposed is unnecessary to cover this particular issue. (There may be other things that this resolution solves, but then there should be an issue for it, I believe.) All the best, Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Tuesday, April 13, 2004 2:37 PM > To: uml2-superstructure-ftf@omg.org > Subject: RE: Official Ballot 11 -- Please vote > > > Thomas, et al, > > > To indicate constants on parameters one uses the value specification > > associated as default value. This will also cover > > ActivityParameterNodes through the associated Parameter. > > It needs to cover all value specifications, not just constants. This > means the time at which the evaluation occurs must be specified and > under the modelers control, ie, it requires an action. Agreed the > example could be more general, which can be taken as a separate issue. > BTW, we probably should file an issue on when parameter defaults are > evaluated. > Reply-To: From: "Conrad Bock" To: Subject: RE: Official Ballot 11 -- Please vote Date: Tue, 13 Apr 2004 17:21:21 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Thomas, > The issue asks how to output constants to an activity parameter > node. As Conrad comments below, the current UML specification already > allows constants to be output. In fact, any ValueSpecification, as > requested by your enlarged problem below, can be output using the > mechanism described by me earlier. The filer of the issue (myself) used the term "constant" to mean anything resulting from the evaluation of a value specification. Otherwise, the functionality would be too limited. This raises the issues described in my last message, in particular, allowing the modeler to control when the value specification is evaluated. Conrad Reply-To: From: "Conrad Bock" To: Subject: RE: Official Ballot 11 -- Please vote Date: Wed, 14 Apr 2004 09:18:28 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Thomas, > Control over the time of evaluation is not mentioned in the issue The request assumes that the resolution will be consistent with UML. Control over when actions are taken is central to all the behavior models. > description and it is unclear what that even would mean. How can the > value of a value specification depend on the time of evaluation? A value specification covers very general things such as Expression and OpaqueExpression, not just literals (Figure 13). These can be anything an implementor would like, including accessing property values, searching for an object that satisfies certain criteria, etc, which of course change over time. Conrad From: "Thomas Weigert" To: , "Thomas Weigert" Cc: Subject: RE: ,ac, Issue 6491 (Outputting constants) Date: Sun, 25 Apr 2004 12:46:15 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Actually, you don't recall correctly, I am sorry to say. The main reason for leveraging ValuePin was to smoothly integrate the different ways of describing values, depending on what means one uses to describe behavior. Remember that there is: OpaqueExpression (characterizing a computation yielding a value), ValueSpecification itself (to define default values for structural features and parameters), literal values used in behavior definitions (activities, etc.), description of the result of behavior (parameters), inputs and outputs of primitive behaviors (i.e., actions), and so on. Carefully balancing all these means of description while allowing that a tool or profile may use only some of the packages of the UML was actually quite difficult. Metamodel weight was not a concern as much as avoiding duplication and confusion. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, April 25, 2004 10:42 AM > To: Thomas Weigert > Subject: ,ac, Issue 6491 (Outputting constants) > > > As I recall, the only reason for replacing UML 1.5 LiteralAction with > ValuePin was metamodel weight, with the intention of preserving > functionality. Since ValuePin doesn't really do what is needed, I think > we should revert to LiteralAction (or call it ValueAction). Otherwise, > the various domain extensions will need to introduce their own version > of it. > From: "Thomas Weigert" To: , "Thomas Weigert" Cc: Subject: RE: ,ac, Issue 6491 (Outputting constants) Date: Sun, 25 Apr 2004 13:02:51 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Conrad, thanks for the example. I think this example shows us an interesting problem. In the activity model we have apparently two ways of doing a conditional: (i) Using, as in this example, the decision node and some constraints on the outgoing flows, and (ii) using a ConditionalNode. These two are identical in concept, can be used in the same place of the model, but have slightly different capabilities. This is a problem I would tackle before adding even more elements to the action model... Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, April 25, 2004 10:42 AM > To: Thomas Weigert > Subject: ,ac, Issue 6491 (Outputting constants) > > > > Hi Thomas, > > Finally remembered the original reasion for an action that evaluates > value specifications: to determine the output constant dynamically, ie, > sometime the activity outputs 3 sometimes 4. An example is shown in > http://www.omg.org/cgi-bin/doc?ad/04-01-12, Figure 15-28. OMG Issue No: 6491 Title: Outputting constants Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: How are constants introduced in a flow, eg, to output a constant to an activity parameter node? UML 1.5 had GetLiteralAction to output a constant. Reintroduce it or some construct that has the same effect. Discussion: ValuePin is a lind of InputPin that provides inputs to actions based on value specifications. It has the following problems: ValuePin cannot provide values for output activity parameter nodes. In particular, it cannot be used to dynamically choose what value specification to output to an activity paramater nodes, for example, with a decision node (see example below). ValuePin is is not flexible in when it is evaluated. It can only be evaluated as an input to an action when the other inputs are already available. It has been suggested to use a value specification as a default value for an output parameter, but this does not address either of the above problems. Consequently it is not backwardly compatible with UML 1.5 LiteralAction. Add an action for evaluating a value specification as described below. In Figure 144, add ValueSpecificationAction, as shown (with change from 6222, and consolidated layout): In Actions chapter, insert new entry for ValueSpecificationAction alphabetically as follows: ValueSpecificationAction ValueSpecificationAction is an action that evaluates a value specification. Description This action returns the result of evaluating a value specification. Attributes None. Associations value : ValueSpecification [1..1] (Specialized from Action:output) Value specification to be evaluated. Constraints [1] The type of value specification must be compatible with the type of the result pin. [2] The multiplicity of the result pin is 1..1. Semantics The value specification is evaluated when the action is enabled. Notation The action is labelled with the value specification, as shown below. Figure . ValueSpecificationAction notation Examples The figure below shows a value specification action used to output a constant from an activity. Figure . Example ValueSpecificationAction Rationale ValueSpecificationAction is introduced for injecting constants and other value specifications into activity flow. Changes from previous UML ValueSpecificationAction replaces LiteralValueAction from UML 1.5. Disposition: Resolved From: "Thomas Weigert" To: "Conrad Bock" , Subject: RE: ,av,,ac, Activity/action resolutions for ballot 16 Date: Sun, 30 May 2004 17:54:58 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Conrad, you really worked hard... A few comments: 1. Issue 6491: I have objected to this resolution earlier on the basis that what is requested by the issue can already be done in the current specification without introducing additional features. In addition, the feature duplicates functionality already present. I had assumed that we would be working out a solution that removes this duplication, if a resolution is indeed required. You just resubmitted the old issue. 2. Issue 7319: Looking at the assignment spreadsheet, this issue is assigned to me. I have circulated a proposal for a resolution which you might want to comment on. 3. Issue 7337: I believe you did not fully appreciate the problem described in the issue. Also, the two comments on the issue you make are, I believe, incorrect. For example, I can speak of the link induced by a connector but I do not have association ends in the model to address them. However, in an action, I might want to explicitly create such links. I believe that there is a real issue that was pointed to here and would prefer if we could spend some more time working on understanding the issue. 4. Issue 7378: I would prefer I would were to not just brush off the issue by saying "Common behavior is overly general." I believe that activities have gratuitously introduced a way of communicating that is needlessly different to how things are done in the other behaviors and also to how it is done in real life systems. I have implemented a stream-based language in a compiler once, and I can tell you this is not easy. It is not the job of the UML to introduce research features. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, May 30, 2004 4:21 PM > To: uml2-superstructure-ftf@omg.org > Subject: ,av,,ac, Activity/action resolutions for ballot 16 > > > > > Hi all, > > Here are some proposed resolutions (23) in activities/actions for ballot > 16. > Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,av,,ac, Activity/action resolutions for ballot 16 Date: Wed, 2 Jun 2004 09:47:24 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, Thanks for your comments, see replies below. Conrad > 1. Issue 6491: I have objected to this resolution earlier on the > basis that what is requested by the issue can already be done in the > current specification without introducing additional features. How would you do the example given in the resolution? > 2. Issue 7319: Looking at the assignment spreadsheet, this issue is > assigned to me. That's an error, since it is about activities/actions. Bran, please reassign 7319 to me, thanks. > 3. Issue 7337: I believe you did not fully appreciate the problem > described in the issue. Also, the two comments on the issue you make > are, I believe, incorrect. For example, I can speak of the link > induced by a connector but I do not have association ends in the > model to address them. However, in an action, I might want to > explicitly create such links. I believe that there is a real issue > that was pointed to here and would prefer if we could spend some more > time working on understanding the issue. Sure, can you elaborate? > 4. Issue 7378: I would prefer I would were to not just brush off the > issue by saying "Common behavior is overly general." I believe that > activities have gratuitously introduced a way of communicating that > is needlessly different to how things are done in the other behaviors > and also to how it is done in real life systems. I have implemented a > stream-based language in a compiler once, and I can tell you this is > not easy. It is not the job of the UML to introduce research > features. The term "stream" might be midleading, since it refers to when inputs and outputs are provided/taken, rather than, for example, the unix notion of stream. It is used heavily at the analysis level of process modeling. Please correct me, but the issue text implied that common behavior can restrict the specialized behavior models. I can restate > Conrad From: "Thomas Weigert" To: , "uml2ftf" Subject: RE: ,av,,ac, 6491 Date: Thu, 10 Jun 2004 08:56:57 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Conrad, comments... 1. Your example does not require "dummy operations" but merely an invocation of a behavior defined by an activity that involves a conditional action as opposed to a decision at the activity level. Maybe you are referring to "dummy behaviors" as operation has a very specific meaning in the UML? Note that "1" or "2" are primitives of activities only by a large stretch of imagination. You will find these situations more likely in defining actions in an action language, and there the situation is a non-issue. Per your other emails, having vast numbers of "dummy behaviors" in the model appears not to be a problem, though... 2. It is almost humorous for you to have a complaint about "dummy" elements. In separate threads you are imposing a vast number of "dummy activities" on the user to express simple things such as time constraints or reference to actions from interactions or state machines. I think what is good for the goose.... I actually do agree with you that we should not have awkward models just so that we can straightjacket something into design choices that had been made earlier. But this should apply in general, not only when it is convenient to your case? Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Wednesday, June 09, 2004 2:35 PM > To: uml2ftf > Subject: RE: ,av,,ac, Activity/action resolutions for ballot 16 > > > - 6491 (Outputting constants) > > How can the example be done currently without dummy operations? > Dummy operations never go over well with users or vendors. > Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,av,,ac, 6491 Date: Thu, 10 Jun 2004 14:46:57 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, Thanks for the followup. > 1. Your example does not require "dummy operations" but merely an > invocation of a behavior defined by an activity that involves a > conditional action as opposed to a decision at the activity > level. ConditionalAction has no notation and is for code-oriented modeling, rather than flow modeling. These are different audiences, see http://www.jot.fm/issues/issue_2003_07/column3. In any case, the value still must be injected into the conditional action somehow, and currently the ValuePin (an input pin) is the only way to do it. So the conditional would have input value pins that each flow to an output pin on only one of the conditional branches. Even more cumbersome than dummy behaviors, see next. > Maybe you are referring to "dummy behaviors" as operation has a very > specific meaning in the UML? At one point I thought you had suggested handling the example with value input pins and behaviors that did nothing but pass their input to their output. Was calling these "dummy behaviors". > Note that "1" or "2" are primitives of activities only by a large > stretch of imagination. Didn't follow this. The value specification could be much more complex and still yield an integer. It might even depend on when it is evaluated, and it is useful to see this temporal aspect in the flow model. > You will find these situations more likely in defining actions in an > action language, and there the situation is a non-issue. Also didn't follow this. An action language is a concrete syntax of the model. > Per your other emails, having vast numbers of "dummy behaviors" in > the model appears not to be a problem, though... > > 2. It is almost humorous for you to have a complaint about dummy" > "elements. In separate threads you are imposing a vast number of > "dummy activities" on the user to express simple things such as time > constraints or reference to actions from interactions or state > machines. I think what is good for the goose.... These are imposed by the way other behaviors use activities, which use Activity or Behavior, not Action. In fact you have been a major proponent of that. Fixing this is a much longer range problem. I'm not in favor of doing half the job in the FTF and leaving the rest to profilers. > I actually do agree with you that we should not have awkward models > just so that we can straightjacket something into design choices that > had been made earlier. But this should apply in general, not only > when it is convenient to your case? It's not my case as much as the case of how the other behaviors use activities. Agreed it is an important problem, but it is outside the scope of activities and too much for the FTF. OMG Issue No: 6491 Title: Outputting constants Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: How are constants introduced in a flow, eg, to output a constant to an activity parameter node? UML 1.5 had GetLiteralAction to output a constant. Reintroduce it or some construct that has the same effect. Discussion: ValuePin is a kind of InputPin that provides inputs to actions based on value specifications. It has the following problems: ValuePin cannot provide values for output activity parameter nodes. In particular, it cannot be used to dynamically choose what value specification to output to an activity paramater nodes, for example, with a decision node (see example below). ValuePin is is not flexible in when it is evaluated. It can only be evaluated as an input to an action when the other inputs are already available. A number of alternatives have been suggested: · Use a ValuePin with a CallBehaviorAction to a dummy behavior that outputs the same value that is input to it. Most users find dummy behaviors too cumbersome. · Use a value specification as a default value for an output parameter. This does not address either of the above problems with ValuePin, since they cannot be used for dynamically chosen values (see example below). · Use ConditionalAction with input value pins that each flow to an output pin on only one the conditional branches. This is even more cumbersome than dummy behaviors. Consequently, the current metamodel is not backwardly compatible with UML 1.5 LiteralAction. Add an action for evaluating a value specification as described below. In Figure 144, add ValueSpecificationAction, as shown (with change from 6222, and consolidated layout): In Actions chapter, insert new entry for ValueSpecificationAction alphabetically as follows: ValueSpecificationAction ValueSpecificationAction is an action that evaluates a value specification. Description This action returns the result of evaluating a value specification. Attributes None. Associations value : ValueSpecification [1..1] (Specialized from Action:output) Value specification to be evaluated. Constraints [1] The type of value specification must be compatible with the type of the result pin. [2] The multiplicity of the result pin is 1..1. Semantics The value specification is evaluated when the action is enabled. Notation The action is labelled with the value specification, as shown below. Figure . ValueSpecificationAction notation Examples The figure below shows a value specification action used to output a constant from an activity. Figure . Example ValueSpecificationAction Rationale ValueSpecificationAction is introduced for injecting constants and other value specifications into activity flow. Changes from previous UML ValueSpecificationAction replaces LiteralValueAction from UML 1.5. Disposition: Resolved Conrad