Issue 11810: MARTE PAM Parameters for behaviour demanded by a Step (marte-ftf) Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca) Nature: Uncategorized Issue Severity: Summary: A PaStep can make a demand for a behaviour, much like a macro, to be included in the Step. An example of the use of this, is to include a complex handshake protocol for exchanging a message between objects on different nodes. The profile has behaviourDemands: list of Scenarios to be included behaviourCount: corresponding list of number of invocations during the step It also should support parameters to the Scenario, such as the message size. This requires a way of binding a value in the invocation to a value in the Scenario. Possible resolution: Add behaviorParm : a corresponding list of tuples. Each element of a tuple could be expressed as (variable=value), with the variable name corresponding to the variable used in the Scenario More complex and powerful resolution: Let the context variables decdlared for a Scenario be implicitly regarded as an ordered list of arguments, when the Scenario is invoked. The tuple could then give just the values for the list. A NUL value could be used to mean, do not override the value given within the Scenario. The same considerations apply to PAM::externalOpDemands. A similar concern applies to GQAM::servDemands, but the resolution may have to be different as Operations already have arguments and the defining scenario is attached indirectly. A broader version of this issue is parameterizing behaviours in general: it seems to be incomplete in MARTE. Resolution: withdrawn by submitter Revised Text: Actions taken: December 9, 2007: received issue March 25, 2008: closed issue Discussion: End of Annotations:===== te: Sun, 9 Dec 2007 11:13:02 -0500 (EST) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: issues@omg.org Subject: MARTE PAM Parameters for behaviour demanded by a Step A PaStep can make a demand for a behaviour, much like a macro, to be included in the Step. An example of the use of this, is to include a complex handshake protocol for exchanging a message between objects on different nodes. The profile has behaviourDemands: list of Scenarios to be included behaviourCount: corresponding list of number of invocations during the step It also should support parameters to the Scenario, such as the message size. This requires a way of binding a value in the invocation to a value in the Scenario. Possible resolution: Add behaviorParm : a corresponding list of tuples. Each element of a tuple could be expressed as (variable=value), with the variable name corresponding to the variable used in the Scenario More complex and powerful resolution: Let the context variables decdlared for a Scenario be implicitly regarded as an ordered list of arguments, when the Scenario is invoked. The tuple could then give just the values for the list. A NUL value could be used to mean, do not override the value given within the Scenario. The same considerations apply to PAM::externalOpDemands. A similar concern applies to GQAM::servDemands, but the resolution may have to be different as Operations already have arguments and the defining scenario is attached indirectly. A broader version of this issue is parameterizing behaviours in general: it seems to be incomplete in MARTE. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca Date: Tue, 5 Feb 2008 12:28:37 -0500 (EST) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: marte-ftf%omg.org@sce.carleton.ca Subject: issue 11810 (PAM) parameterized behavior The idea is to allow to invoke a behaviour with parameters, which are also the parameters of its analysiscontext. Thsi would allow to re-use behaviours in different varieties within a single larger scenario, and seems very desirable. This discussion/proposal especially asks a response from Huascar Espinoza. Notice that some of this can be done using global variables of the larger analysisContext, and using consistent variable names in the nested contexts, without giving them values there. However this solution is rigid and fragile, depending on consistent variable naming. At the moment, some scenarios can be incorporated like macros, within a step, by providing behaviorScenario = list of scenarios and behaviorCount = list of counts for number of invocations. A solution for defining the parameters for the macro call is to provide a third list of tuples, one for each scenario. Each tuple would be some number of entries, one per parameter, of type <>. This type can be written parametername:type = valueExpression, which would be suitable for the parameter list. Example: suppose a step uses two scenarios B1 (once) and B2 (twice), and B1 has three parameters $v1, $v2, $v3, while B2 has two parameters $x and $y. The invocation could be written as three ordered lists in correspondence: behaviorScenario = (B1, B2) behaviorCount = (1, 2) behaviorParam = (($v1 = 3.7, $v2 = $a + 16 * $b, $v3 = $v1 + $v2), ($x = 1/$a, $y = $z)) Notice that the scenario takes in variables $a $b $z from the calling context, which are provided with values there. The definition of context variables and values is defined in GQAM but the best example is Fig 16.14 p 307. The variables are properties of VSL::Variables::ExpressionContext, inherited by analysisContext (see Fig 15.6. Suggested resuolution therefore is: add attribute behaviorParams:behavPars [*]{ordered} and add dataType behavPars:var[*]. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) Date: Tue, 5 Feb 2008 15:20:48 -0500 (EST) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: marte-ftf@omg.org Subject: issue 11810 (PAM) parameterized behavior The idea is to allow to invoke a behaviour with parameters, which are also the parameters of its analysiscontext. Thsi would allow to re-use behaviours in different varieties within a single larger scenario, and seems very desirable. This discussion/proposal especially asks a response from Huascar Espinoza. Notice that some of this can be done using global variables of the larger analysisContext, and using consistent variable names in the nested contexts, without giving them values there. However this solution is rigid and fragile, depending on consistent variable naming. At the moment, some scenarios can be incorporated like macros, within a step, by providing behaviorScenario = list of scenarios and behaviorCount = list of counts for number of invocations. A solution for defining the parameters for the macro call is to provide a third list of tuples, one for each scenario. Each tuple would be some number of entries, one per parameter, of type <>. This type can be written parametername:type = valueExpression, which would be suitable for the parameter list. Example: suppose a step uses two scenarios B1 (once) and B2 (twice), and B1 has three parameters $v1, $v2, $v3, while B2 has two parameters $x and $y. The invocation could be written as three ordered lists in correspondence: behaviorScenario = (B1, B2) behaviorCount = (1, 2) behaviorParam = (($v1 = 3.7, $v2 = $a + 16 * $b, $v3 = $v1 + $v2), ($x = 1/$a, $y = $z)) Notice that the scenario takes in variables $a $b $z from the calling context, which are provided with values there. The definition of context variables and values is defined in GQAM but the best example is Fig 16.14 p 307. The variables are properties of VSL::Variables::ExpressionContext, inherited by analysisContext (see Fig 15.6. Suggested resuolution therefore is: add attribute behaviorParams:behavPars [*]{ordered} and add dataType behavPars:var[*]. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) Date: Tue, 18 Mar 2008 10:20:17 -0400 (EDT) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: issues@omg.org Subject: MARTE issue 11810 withdrawn I raised this issue. The discussion has convinced me that the change is unnecessary, and it has no support, so I withdraw it. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html)