Correction: Re: [tag] TA Condition Qualifiers and TA Dependencies

[stephen.green@systml.co.uk]

Erratum:

Sorry for the example please read:

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

['then item X' instead of 'then item A']

Quoting 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
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php