[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] Update to Multiple Specifications section
This is great; thanks Kevin, I'll add it to the wiki draft. I'm just waiting for a couple more action items then I'll prepare another document draft. All the best Steve On 13/08/2008, Kevin Looney <Kevin.T.Looney@sun.com> wrote: > Here is another revision of the Multiple Specifications section, updating > from some of our notes from the F2F. > > Please feel free to add recommendations and suggestions. > > Steven - this rework is probably further along than what last appears in the > draft - perhaps we should include this in the draft for now? > > Jacques - the first subsection of 3.6.2 is now more generalized to describe > a broader range of scope for specifying conformance in both predicates and > prerequisites (per your suggestions). I've kept the same previous examples > however for simplicity. > > Thanks, > 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". For > proper specification analysis, inclusion of test assertions from both the > umbrella 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 specs > 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 AssertionThere are three dimensions that describe how > assertions from a referenced specification may be included within an > umbrella specification: > 'scope of inclusion', 'conditionality of inclusion', 'modification of > inclusions'. These relationships between specifications can be expressed > using a TA. This form of a TA is a specific form of an 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 TAs from a reference spec may be conditionally included > in an umbrella spec). > Scope of Inclusions > Relationships between the (current) umbrella specification and a referenced > spec are usually described via conformance statements. These conformance > statements can be expressed in a TAs prerequisite or predicates. > > The scope of this conformance may be determined by the expressions in these > prerequisites or predicates. > > A predicate may describe the target conforms to varying scopes of the > (current) umbrella specification as follows: > > an (entire) umbrella specification > a conformance profile of the umbrella specification > a specific normative statement from the umbrella specification Similarly, a > prerequisite may describe the target conforms to varying scopes of the > external specification as follows: > > an (entire) referenced specification > a conformance profile of an referenced specification > a specific TA from an referenced specification A simple example might be a > wholesale inclusion that describes where a target in an umbrella > specification is completely conformant to the assertions of a referenced > specification. > > TA id: widget-TA100-8 > Target: Widget > Normative Source: 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: "All widgets conformant to the WidgetSpec1.0 must also be > conformant to the Mini-Widget Small Box Specification 1.2"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 WidgetSpec1.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 spec be implemented > in the umbrella, > b. conditionally require optional portions of the referenced spec 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 spec 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 > spec is conformant to "unchanged". The remaining Test Assertions (changed > set) can be individually specified as TAs of the umbrella spec. > > 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 -- Stephen D. Green Partner SystML, http://www.systml.co.uk Tel: +44 (0) 117 9541606 Associate Director Document Engineering Services http://www.documentengineeringservices.com http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]