[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Wiki further updated
Thanks Kevin for getting this in by deadline I've updated the wiki further still (maybe too much but I thought I had today as target for getting it all up to date with plan to create document file version tomorrow and Friday). There could be a need for tweaking, still to do. Still hoping Paul gets Versions section in today. Wiki's nearing state for next hard draft anyway. I'll say target time is around end of Schedule B call (this evening US Pacific time) and see what we have at start of day tomorrow from which to start the next hard draft. If anyone gets a chance to proof-read for typos, bad wording, errors, etc by then it would be a good help, thanks. I'll do some proof reading too. Thanks again best regards Steve 2008/9/24 Kevin Looney <Kevin.T.Looney@sun.com>: > 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). > -- 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]