Introduction
...
- the first pages in Chapter 10 of the OMG SBVR specification version 1.1;
- this presentation available on the Web (in particular slides 5 and 6).
...
| SBVR Definition:
|
| SBVR Definition:
|
| SBVR Definition:
|
| SBVR Definition:
|
| SBVR Definition
|
...
Special case | NounConcept construction rules | ||
Concatenation - when necessary to identify an UML model element that is remote from the current class. For example, a rule defined for the AirportHeliport class that needs to refer to the name attribute of the associated City class. | The "." symbol is used as separator between the concatenated noun concepts. The relative path needs to include all the intermediate association role names and class names, as in the following example: servedCity.City.name. | ||
Association classes - Some associations are qualified by a number of properties depicted inside an 'association class'. For example, the association between Airspace and another AirspaceVolume includes the AirspaceGeometryComponent association class. | When the NounConcept is inside the association class, the path includes first the name of the association role, concatenated with the association class name and with the property name concerned. For example: geometryComponent.AirspaceGeometryComponent.operation. | ||
Specialisation - Inheritance is frequently used in the AIXM UML model. The class that is specialised is always stereotyped <<abstract>> and does not appear as such in the AIXM XML Schema. Only its non-abstract specialisations appear in the Schema. Inheritance could occur with more than one level of specialisation (for example, the Service class) | In general, the class that is specialised is used as NounConcept, followed by the "specialisation" fact-type and by the name of the derived class (also a NounConcept). For example: "... NavaidEquipment specialisation TACAN…". | ||
Data type attributes - For example, most "Val…" data types come with a "uom" attribute. | The uom attribute appears directly in the path after the attribute name, prefixed with a '.'. For example, the rules that require the mandatory presence of a uom value for an elevation attribute use the following noun concept path: elevation.uom. | ||
TimeSlice - Not present in the UML model, but appearing directly in AIXM XML Schema, based on the AIXM Temporality Concept (see in particular section 2.8 in that document). For example, rules that check the correctness of the validTime with regard to the type of TimeSlice. | The following properties introduced for each and every AIXM <<feature >> class may appear as noun concepts:
| ||
GML elements - Present only partially in the UML model, through the GM_… classes. However, the details of these classes are missing in AIXM 5.1. For example, positions are encoded with the gml:pos element, while surfaces use much deeper structures, such as gml:Surface.gml:... | Specific GML 3.2.1 schema elements appear as NounConcepts, such as:
| ||
Different instances - When a rule concerns two different instances of the same NounConcept and it is necessary to distinguish between the two. For example, a rule for the uniqueness of 5-letter designators needs to refer to different instances of the DesignatedPoint class. | A number in square brackets is used in order to distinguish the two, such as in the following example: DesignatedPoint
. |
...
Keyword | Explanation | Way of use in SBVR AIXM Profile |
|---|---|---|
a, an | universal or existential quantification | depending on context based on English rules |
assigned value | existential quantification (that the referent thing is not null) | for readability reasons (and to comply with the English language syntax), it is usually written as follows: |
with | has fact type plus a condition on the property or descendant | used as a simplified form of: |
that | existential quantification for a part of a condition starting with a verb concept | typically used in front of the verb concept, between two noun concepts with associated conditions |
equal-to | existential quantification plus a condition that the referent thing is the same thing as the referent of the term that comes next | typically used in front of a Name or a list of Names, when the item also has to exist |
higher-than | existential quantification plus a condition that the referent thing is a numerical value that is larger than the referent of the term that comes next | typically used after a noun-concept in the form of a class attribute that takes numerical values |
higher-or-equal-to | existential quantification plus a condition that the referent thing is a numerical value that is larger than or equal to the referent of the term that comes next | typically used after a noun-concept in the form of a class attribute that takes numerical values |
lower-than | existential quantification plus a condition that the referent thing is a numerical value that is smaller than the referent of the term that comes next | typically used after a noun-concept in the form of a class attribute that takes numerical values |
lower-or-equal-to | existential quantification plus a condition that the referent thing is a numerical value that is smaller than or equal to the referent of the term that comes next | typically used after a noun-concept in the form of a class attribute that takes numerical values |
resolved-into | existential quantification plus a condition that the value of the noun-concept that precedes the keyword corresponds to an instance of the verb and noun-concept that come next | used to indicate the action of evaluating the value of an association role name instance and identifying the target feature instance, taking into consideration the associations implementation method used (according to the AIXM Feature Identification and reference document) |
other-than | at-most-one quantification plus condition that the referent thing is not the same thing as the referent of the term that comes next | typically used in front of a Name or a list of Names, when the item may also be null |
...