[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] Added text about Variables in TA Guidelines
Many thanks David for good feedback comments on variables and for the example which ties in nicely too with issue i031 to provide a way to formulate a TA whose purpose is to determine an output value while still itself evaluating to a boolean value. The TA determines that the encoding has value DEFAULT-ENCODING and DEFAULT-ENCODING is itself a variable determined by in input value - input to the TA that is. I like it. I'll add the example. I guess we'll need a short sentence to introduce it. I'll formulate one but would appreciate it if you'd look it over when posted. Thanks. Maybe we can lead from here to a solution on not just issue 31 but also the wider application of this kind of TA to not just determine a predicate value but other, non boolean values too. -- Stephen D. Green Partner SystML, http://www.systml.co.uk Tel: +44 (0) 117 9541606 http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice Quoting david_marston@us.ibm.com: > I think Stephen's verbiage about variables is headed in the right > direction. It might help to talk about scope a little bit more. > > In the case of the geo-political location or (my last example) the default > collation, it is significant that the variable is set once and applies > globally across all TAs that make reference to it. The same would apply to > modules/profiles/levels: once the IUT has been assessed as implementing a > certain level or aiming to support a particular profile or supporting > certain modules (or not), then all the relevant TAs can be filtered and > their implications properly cascaded. This is an operation that should > only happen once per run of a test suite. Thus, a standardized design for > TAs helps improve the design of test harnesses because the design can be > based around resolving all the variables before running any test cases > that depend on those variables. > > The earlier example of the fuse rating is more local in scope, but may > still be an interesting usage for variables. > > Finally, I note that your example does not have a tie between the variable > input to the TA and the result of the test. The default-encoding example > shows this situation, so I think you should add this as another example. > NOTICE that this example does NOT use the variable in a pre-req, hence it > is significantly different from the geo-political widget example. > Variable: 'DEFAULT-ENCODING' the identification of the encoding used on > XML output when no other encoding has been given. Type is string, because > there is no universal enumeration of all possible encoding IDs. > TA id: frammis-1 > Target: any frammis > Normative Source: specification requirement 105, part 17 > Predicate: If [the frammis] was not dynamically told which encoding to > use, its output has DEFAULT-ENCODING encoding. > Prescription Level: mandatory > To summarize: variables have a role as both inputs to and outputs of a TA. > .................David Marston
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]