Re: [tag] Added text about Variables in TA Guidelines

[stephen.green@systml.co.uk]

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