[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag] Update to section 3.6 (Multiple Specifications)
Kevin:
Looks definitely better to me :-)
I have posted a couple of suggestions in the wiki to make the 2 first
examples more intuitive...
(and more illustrative of the referencing patterns: base / derived and
umbrella / referenced.)
For review / comments.
Jacques
-----Original Message-----
From: Kevin.T.Looney@Sun.COM [mailto:Kevin.T.Looney@Sun.COM]
Sent: Wednesday, September 24, 2008 9:59 AM
To: TAG TC
Cc: stephen.green@documentengineeringservices.com
Subject: [tag] Update to section 3.6 (Multiple Specifications)
Hi everyone,
I updated section 3.6 according to Jacques' recommendations. The
text is below, and will appear in the wiki. Stephen, please feel free
to tweak any of the text.
Thanks, Regards,
Kevin L
========================================================================
============================
3.6 The Case of Multiple Specifications
Modularity and succinct description within specifications can be
achieved by leveraging existing specifications that are referenced by
other specifications. Specification writers often create "umbrella
specifications". These are widely scoped specifications that delegate
certain normative descriptions to other "referenced specifications".
Specification modularity may also come from /prototypical
/specification, such as a "base specification", from which specialized
derivative specifications may define specific information for a given
context.
For proper specification analysis, inclusion of test assertions from
both the umbrella (or base) specification and all the referenced
specifications should be considered.
Two aspects of analysis of multiplicity of the normative sources are
considered:
* Specification Visibility (Section 3.6.1) deals with how assertions
from a referenced specification are considered or described in the
umbrella specification
* Composition of Assertions (Section 3.6.2) describes how predicates
and prerequisites can express various relationships between umbrella and
referenced specifications
3.6.1 Specification Visibility
Consider a case where a specification is the normative source but it
itself refers normatively to a second specification. Consider firstly
the case where there is no visibility of any test assertions covering
this second specification. Here there may be a prerequisite that all
test assertions for the second specification be treated as a single
Boolean requirement.
In a second case the specification refers to a second specification for
which the test assertions are given visibility and here the test
assertions of the first specification may refer to individual or groups
of test assertions of the second specification as explicit
prerequisites. Of course, any number of normative sources may be
involved, some with test assertions visible, others not.
3.6.2 Composition of Assertion
There are three dimensions that describe how test assertions for an
umbrella specification can refer to another specification:
'scope of inclusion',
'conditionality of inclusion',
'modification of inclusions'.
These relationships between specifications can be expressed using a test
assertion. This form of a test assertion is a specific form of a test
assertion, as it expresses some form of conformance (like a conformance
clause).
Multiple dimensions can be expressed within these relationships (for
example, a subset of test assertions from a reference spec may be
conditionally used in an umbrella specification).
Scope of Inclusions
An umbrella specification usually relates to a referenced specification
by assuming or requiring conformance of its implementation to this
specification.
These conformance requirements can be expressed in a test assertion's
prerequisite or predicates.
The scope of this conformance may be determined by the expressions in
these prerequisites or predicates.
The logical expressions used in the predicate may also include a
conformance requirement for varying scopes of the (current) umbrella
specification as follows:
* conformance to an (entire) umbrella specification
* conformance to a profile of the umbrella specification
* conformance to a specific normative statement from the umbrella
specification
Similarly, the logical expressions used in a prerequisite may also
include a conformance requirement for varying scopes of the external
specification as follows:
* conformance to an (entire) referenced specification
* conformance to a profile of an referenced specification
* conformance to a specific test assertion from an referenced
specification
A simple example might be a wholesale inclusion that describes where a
target in an derivative specification is completely conformant to the
assertions of a base specification.
*
TA id: widget-TA100-8
Target: Widget
Normative Source: Conformance clause of WidgetSpec 1.0
Prerequisite: [the widget] is conformant to Mini-Widget Small Box
Specification 1.2
Predicate: [the widget] is conformant to WidgetSpec 1.0
Prescription Level: mandatory
*
Interpretation: "A widget that conforms to the Mini-Widget Small Box
Specification 1.2. must be conformant to the WidgetSpec 1.0
specification."
Another example might be a partial inclusion that describes a case where
a target in an umbrella specification is conformant to some subset of
assertions in a referenced specification. Subsets of a specification are
described as 'Conformance Profiles', and may be expressed via grouping
constructs (using 'lists'):
TA id: widget-TA100-9
Target: Widget
Normative Source: WidgetSpec 1.0
Prerequisite: [the widget] is conformant to the "smaller
box" Conformance Profile of the Mini-Widget Small Box Specification 1.2.
Predicate: [the widget] is conformant to WidgetSpec 1.0
Prescription Level: mandatory
Note: "Some portion of the TAs for the Mini-Widget Small Box
Specification 1.2 are identified in a list to indicate their inclusion
in the Smaller Box conformance profile"
Interpretation: "All widgets conformant to the WidgetSpec 1.0
specification must also be conformant to the 'smaller box' assertions of
the WidgetMobile Small Box Specification 1.2"
Conditionality of Inclusions
This dimension of inclusion describes the conditionality whether
assertions in an umbrella specification is conformant to a referenced
specification. The prerequisite of the assertion may:
* a. require that optional portions of the referenced specification
be implemented in the umbrella,
* b. conditionally require optional portions of the referenced
specification be implemented in the umbrella (for example, based on the
presence of hardware or some other such support), or
* c. make remaining (required) portions of the referenced
specification be optional
The example of widget-TA100-8 already shows how a widget describes
mandatory conformance. The following widget describes a conditional
conformance:
*
TA id: widget-TA100-10
Target: Widget
Normative Source: specification requirement 120 in WidgetSpec 1.0
Prerequisite: IF [the widget] has restriction of box size 760 mm x
480 mm x 100 mm or less THEN [the widget] is conformant to the
Conformance Profile of the Mini-Widget Small Box Specification 1.2.
Predicate: [the widget] is conformant to WidgetSpec 1.0
Prescription Level: mandatory
Interpretation: "All widgets conformant to the WidgetSpec1.0
specification must also be conformant to the assertions of the
WidgetMobile Small Box Specification 1.2 IF the widget is smaller (or
equal) in size to 760 mm x 480 mm x 100 mm "
Modification of Inclusions
This dimension of inclusion describes where an umbrella specification is
conformant to a referenced specification, where some subset of
assertions must be modified. This assumes some partitioning of the
unchanged assertions and modified assertions. You can use "lists of
assertions" to describe in the pre-requisite the subset of assertions
that the umbrella specification is conformant to "unchanged". The
remaining test assertions (changed set) can be individually specified as
test assertions of the umbrella specification.
Typically, assertions are modified in a referenced specification to be
strengthened in a few ways:
*
strengthening the prescription level of an assertion (eg. x MAY do
y => x MUST do y), or
*
strengthening the meaning of an assertion with additional
requirements (eg. IF x THEN z => IF (x AND y) THEN z).
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]