TA Condition Qualifiers and TA Dependencies

[stephen.green@systml.co.uk]

I just want to attempt to clarify those couple of points as
requested in the F2F. Here is an example I'd like to work with

Example 1:
Spec: #2: item X MAY have property Y
       #3: if item X has property Y then item A MUST have property Z1
       #4: if item X has property Y then item A MUST have property Z2

(Z1 and Z2 might, say, be properties somehow related to Y)

It might be that the spec writers realize they have to further
qualify this to help with the conformance issue: What happens
when #3 or #4 are not satisfactorily implemented?

case 1: if #3 or #4 fails then #2 also fails
case 2: if #3 or #4 fails #2 does not necessarily fail because it is optional
case 3: if #3 then #2 fails but if #4 fails then 2# does not necessarily
fail

(I'll give a normal life version of Example 1 just to show how realistic
it might be in a familiar situation:
Example 2 - some local traffic light requirements:
If traffic light fails in a part of a road that doesn't need one then it
depends what sort of failure it is as to whether it MUST be replaced: if
it fails to light up at all then it is OK but if it shows green when it
should show red it MUST be replaced or fixed
If a traffic light fails in a part of a road where it is essential then
it MUST be replaced or fixed whatever the failure

X = road position
Y = traffic light
Z1 = sequencing program
Z2 = power supply)

back to Example 1

How about the TAs (especially for case 3)?

I would say we can use conditions to qualify the TAs in order
to show the dependencies between outcomes. This is nothing
new, except that I'm favoring 'condition' over 'precondition'
since it covers things where time is relevant - such as cause
and effect - but also where it isn't - such as logical if..then.
So I'd see a condition (such as 'when..then' or 'if..then') as
a qualifier of part of the TA expression.

Then I'd say the TAs would be additionally linked where there are
dependencies of the conditions on the other TAs. (This is like
the 'prerequisite' concept of the WS-I prior art where a
'prerequisite' is apparently a precondition which involves
another TA - except that here I'm separating the two concepts
into the link to another TA and the condition which says more
about how the other TA outcome relates to the current TA outcome.)

I feel that conditions and dependencies are more generic than
preconditions and prerequisites and cover more use cases. I feel
that we should split (in modeling at least) the separate roles
prerequisites play of condition/qualifier and TA pointer.

So:
The conditions determine test outcomes.
The dependencies are there to show that the TAs are linked.

Conditions are the qualifiers. The Dependencies are to show
that a TA uses other TAs. There may be reasons to declare
Dependencies to other TAs for other reasons too, not just
for TAs used in conditions.


When the TA is a 'bold assertion' in prose it might contain
the qualifier(s).

When the TA is derived there is the opportunity to structure
it by distinguishing the components. *** Aside: maybe a tool
could do this by sub-highlighting in a different way each different
component: TA target (subject noun), qualifier(s), verb,
object noun (value), dependent TA(s), etc. ***

I would go for this structural breakdown of the TAs:

For case 2, perhaps
TA ID (as usual)
      UUID-TA#2

Spec Ref (as usual)
      UUID-#2

Dependency pointers (links to other TAs required by this one)
      UUID-TA#3  UUID-TA#4

TA Target
      X

TA Target qualifier(s) - some by reference to Dependency pointers
     if UUID-TA#3
     if UUID-TA#4
     (another type of qualifier might say 'when XYZ' speaking
      of an event or time-constrained condition)

TA verb
     has

TA object/value
     property Y

(UUID-TA#3 and UUID-TA#4 are the TAs related to spec statements #3 and #4)


So the outcome would result from X having property Y but
also depend on X having property Z1 according to another TA.

In the real-world example:
The road position has to have a traffic light which has to
have correct sequencing but not necessarily a power supply.
The sequencing and power supply have separate TAs to the
road position TA.

Trickier to deal with case 3.

Although the sequencing of tests is part of the testing, the
dependencies are so close to the spec requirements as to warrant
their being expressed as TA conditions and this means relating
one TA to another and showing that relationship explicitly too.

Best regards
-
Stephen Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice