Comments on section 3.4 (multiple specifications)

[Kevin Looney <Kevin.T.Looney@Sun.COM>]

Hi Everyone,

    Stephen - I had an AI to comment on this section, but it was delayed while I was recovering.

    The placeholder text for this section (3.4) is sufficient, but terse.  I think there are a few main points that mostly need to be hilited:

1.) (primary) specifications may *reference* (component) specifications
2.) References to (component) specifications may be complete (inheriting all TAs) or partial (inheriting a subset of TAs, possibly based on a logical condition).
3.) TAs inherited from a component specification may have a different meaning, based on the context (umbrella) where it is interpreted.  This may lead to modification of the TA, or modification of the implementation (test) extended from the TA

It would be good to give illustrations of each of these characteristics.  I can conjure up some examples - but our colleagues in the KTag showed interest in this topic before, - perhaps they might be able to provide 'real world' examples.

Here are some conjured examples:

1.) (primary) specifications may *reference* (component) specifications

    This specification (S#24355Widg) is the overriding description behavior of Widgets.  S#24355Widg includes specifications of (S#24340WidgEmb) widgets embedded in real-time devices, (S#24344WidgMob) Mobile widgets, and (S#24346WidgConst) widgets in constrained computing environments.

2.) References to (component) specifications may be complete (inheriting all TAs) or partial (inheriting a subset of TAs, possibly based on a logical condition).

S#24355Widg includes specifications for S#24344WidgMob Mobile widgets, with the exception of behaviors specified for continuous connection environments.

3.) TAs inherited from a component specification may have a different meaning, based on the context (umbrella) where it is interpreted.  This may lead to modification of the TA, or modification of the implementation (test) extended from the TA

TA#45:  S#24344WidgMob Mobile widgets specifies that a phone-number look-up must take 3 seconds

This specification (S#24355Widg) includes specification of S#24344WidgMob.

S#24355Widg may be used on spacecraft, approaching the speed of light.

Due to non-constant properties of time as a body approaches the speed of light, TA#45 must be altered to a smaller time boundary (< 3 seconds) to operate correctly in this environment.

[OK - this last example is extremely hypothetical!]


A few other complications from multiple specifications also came to mind:

4.) TAs that conflict

      It is possible that two specification may each contain a similar TA that conflicts the other.  When the specifications stand alone, these TAs do not pose a problem.  However, when the two specifications are joined in a primary specification, a behavioral conflict arises in the specification. 

     This situation would require the primary specification to resolve the conflict (either by discluding one of the behaviors, or modifying the meaning of one of the TAs to be compatible with the other.

5.) Modification of TAs ... to a point.

     Care must be taken when TAs in a referenced specification are modified (for inclusion in a primary specification).  At some particular amount of modification, the TA is fundamentally changed from it's original meaning (in the original specification).  At this point, the author of the primary specification should consider discluding the inherited TA, and creating a new TA within the context of the primary specification.

Hope this helps, Regards,
Kevin L