Introduction
The Semantics of Business Vocabulary and Business Rules (SBVR) standard is used for the writing of the AIXM business rules in relation with the AIXM UML logical data model. This means that the AIXM classes and their properties (attributes and associations), together with their definitions and data types, provide the the "business vocabulary" that is used as the basis for the definition of the AIXM business rules.
This section defines an 'SBVR profile', which is tailored to the AIXM needs and which is documented as a number of concepts and conventions applied in the writing of the AIXM business rules. Two previous projects have provided input material for this document:
- work done by Pulsar Consulting, under contract for Eurocontrol , which is available on the AIXM wiki: Use of SBVR for AIXM ;
- Guidance on Writing AIRM Constraints provided by SESAR Project 08.01.03 .
...
- 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).
...
The following table introduces the concepts used as part of the SBVR Profile for AIXM, including their graphical notation. Note that the use of some graphical notations is simplified as compared to the SBVR standard, such as double underline which is replaced with simple underline. This facilitates the use of standard office tools (such as Microsoft Excel) for the provision of the AIXM set of Business Rules, as double underline is hardly supported.
| SBVR Definition:
|
| SBVR Definition:
Representation in profile (i.e. what AIXM items may appear as NounConcept according to the SBVR profile):
Style: Bold, underlined and UpperCamelCase or lowerCamelCase (depending on how the noun concept appears in the UML model). If several nouns are concatenated, then they should be separated by a dot (".") symbol. |
| 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 |
...