Rules definition using SBVR
- POROSNICU Eduard
SBVR Profile for AIXM
SBVR concepts
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 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:
Fact is a proposition that is taken as true.
Representation in profile (i.e. what AIXM items may appear as Verb-concept according to the SBVR profile):
Style: italic |
| SBVR Definition:
Representation in profile (i.e. what AIXM items may appear as Name according to the SBVR profile):
Style: surrounded by 'simple quotes' |
| SBVR Definition
Representation in profile:
|
NounConcept - special situations
When writing AIXM business rules in SBVR, apart from the simple cases where a class/role/attribute name is used, there are also some special cases, when several classes/associations are involved, as detailed in the following table.
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) | Initially, the class that is specialised was 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…". However, this led to longer rules and SBVR text that is further away from the XML Schema structure, thus more difficult to convert into code that verifies the rules. Change The rules that exist in version 0.8 and that use the specialisation construct will be re-written in version 0.9 For the rules starting with version 0.9, in particular for the ICAO Data Sets, the properties of the abstract (generalised) class are used as if they were directly properties of the specialised class. For example: "...TACAN.location...", although location is a property of the <<abstract>> NavaidEquipment, which is inherited by the TACAN class. |
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 3.8 - "Temporality applied to the abstract model"). 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[1] |
Additional Fact-types
The following table introduces additional fact-types used in SBVR AIXM Profile. They are 'additional' in the sense that they do not appear explicitly as associative facts in the model.
Note: the fact-types marked with an * sign are not used for the moment. They are kept for completeness sake, some might become necessary later.
is-property-of | associative fact type that is defined with respect to a first given concept and a second given concept such that each instance of the fact type is an actuality that an instance of the first concept constitutes an essential quality of an instance of the second concept |
|---|---|
has | describes the same associative fact as "is-property-of", but in the opposite direction: an instance of the second concept constitutes an essential quality of an instance of the first concept
It is important to note that "has" as fact-type cannot be used when referring to the properties of another <<feature>> class, because the two exist independently from each other. They have a different timeline and traversing the association requires also selecting the relevant TimeSlices. This aspect is sufficiently important to be preserved in the SBVR text. In such situations, the association name must be used:
|
is-descendant-of | describes a deeper associative fact than "is-property-of"; an instance of the first concept constitutes a property of a property (and so on…) of an instance of the second concept |
has descendant | describes the same associative fact as "is-descendant-of", but in the opposite direction |
specialisation | categorisation fact type (used to target a specific non-abstract class, that is a specialisation of a parent class; for example NavaidEquipment specialisation VOR) |
categorization* | a particular instance of the concept is also an instance of the category |
is-of-type* | is used for expressing units of measurements (UOM) |
Logical Operations
The following table introduces the logical operations (e.g. "and", "not", "or", etc.) used in the SBVR Profile for AIXM. The exact representation of the operations is in the second column (using keywords convention).
Note 1: The logical expression that defines each AIXM SBVR rule is evaluated applying the usual operators priority/interpretation
- "AND" is evaluated before "OR". For example: TRUE AND TRUE OR FALSE = TRUE. No parenthesis are used in SBVR expressions in order to indicate the order in which the operations are evaluated. The objective is to keep the rules as simple as possible. The lack of parenthesis usually lead to a rule being split into several separate rules. This also leads to more precise diagnostic messages.
- "NOT" applies to the whole expression that follows it, until the next operator (if present) or until the end of the rule. For example: TRUE AND NOT FALSE AND TRUE = TRUE. This is equivalent to "TRUE AND (NOT FALSE) AND TRUE".
Note 2: the keywords marked with an * sign are not used for the moment. They are kept for completeness sake, some might become necessary later.
Logical Operation | SBVR Profile for ATM Representation | Meaning |
|---|---|---|
conjunction | p and q | True when all operands are true |
disjunction | p or q | True when at least one operand is true |
equivalence* | p if and only if q | True when operands are either all true or all false |
exclusive disjunction* | p or q but not both | One operand is true and the other is false |
implication | if p then q | binary logical operation that operates on an antecedent and a consequent and that formulates that the meaning of the consequent is true if the meaning of the antecedent is true |
logical negation | not p | True when the operand is false |
nand* | not both p and q | true when at least one operand is false |
nor* | neither p nor q | true when all operands are false |
whether or not* | p whether or not q | binary logical operation that has a consequent and an inconsequent and that formulates that the meaning the consequent is true regardless of the meaning the inconsequent. |
Quantification
The following table introduces the quantifications (e.g. "at least one") used as part of the SBVR Profile for AIXM. The second column contains the representation (using keywords convention).
quantifier | SBVR Profile for ATM Representation | logic | description |
|---|---|---|---|
universal | each x | ∀ | For each and every x, taken one at a time |
existential | at least one x | ∃ | At least one x |
exactly-one | exactly one x | ∃1 | There is exactly one (at least one and at most one) x |
at-most-one | at most one x | ∃0..1 | There is at most one x |
at-most-n | at most n x | ∃0..n | There is at most n x Note: n is always instantiated by a number ≥ 1. So this is really a set of quantifiers (n = 1, etc.) |
at-least-n | at least n x | ∃n.. | There is at least n x Note: n is always instantiated by a number ≥ 1. So this is really a set of quantifiers (n = 1, etc.) |
at-least-2 | more than one x | ∃n.. | There is at least 2 x. |
exactly-n | exactly n x | ∃n | There is at exactly (at least and at most) n x Note: n is always instantiated by a number ≥ 1. So this is really a set of quantifiers (n = 1, etc.) |
numeric range | at least n and at most m x | ∃n..m | There is at least n and at most m x |
Modality
The following table introduces the modalities (e.g. "It is obligatory") used in the SBVR Profile for AIXM. The fourth column details the representation in the profile.
Note: the keywords marked with an * sign are not used for the moment. They are kept for completeness sake, some might become necessary later.
Modality | SBVR Profile for ATM | Reading (Verbalised as) after applying transformation using negations: |
|---|---|---|
obligation | It is obligatory that p | It is not permitted that not p |
prohibition | It is prohibited that p | It is obligatory that not p |
Note: Please be aware of the distinction between the use of the phrases "It is obligatory that"/"It is prohibited that" and the pattern "Each...shall/should". The latter implies that the target entity or attribute has to exist, whereas this is not always the case. Therefore, the negative formulation is preferred in most cases, as it will check the value only when the entity or the attribute is actually present.
Example:
Each Runway with assigned lengthStrip value shall have assigned lengthStrip.uom value equal-to ('FT','M')
versus
It is prohibited that a Runway with assigned lengthStrip value has lengthStrip.uom value not equal-to ('FT','M').
Additional SBVR keywords
The following table introduces additional keywords that are used in this Profile.
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: Note: a nilReason is not considered an assigned value. |
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 |
| intersects | existential quantification plus a condition that the referent thing is a time interval that has a common portion or that is fully overlapping with another time period. The same term is used in the OGC® WFS Temporality Extension (12-027r4), where it is defined as semantically equivalent to the fes:AnyInteracts operator as defined in OGC® Filter Encoding 2.0 Encoding Standard (09-026r2), 7.9.2 | typically used to compare the timeValid properties of two TimeSlices |
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 |
Methodology
This section is primarily intended for those involved in the writing of the SBVR text of the AIXM Business Rules. However, it might also provide interesting hints for the readers of the document, as it shows how a rule is being developed starting from a fact established by the model, a reference document (such as an ICAO Annex containing Standards and Recommended Practices) and applying the SBVR methodology.
The starting point for writing the SBVR text of a rule is the AIXM UML model, which describes "fact types" such as:
- "Runway isSituatedAt AirportHeliport"
- "name is-property-of AirportHeliport"
- etc.
- Some of these fact types are documented as associations between classes and there is an explicit verb (the name of the association, such as "isSituatedAt"). Some others are attributes of a class (and the verb that describes the fact type is implicitly "is-property-of"). Note that the graphical syntax for NounConcepts and FactTypes is used in these examples, as described earlier in the document.
In the first phase, the objective is to capture the various constraints that are used to define bounds, borders or limits on this set of facts. Any such rule shall have at its core a "fact type". In addition, pure operative rules that are not directly related to a fact type established by the model might also have to be captured. For example, the required accuracy of the boundary points of a restricted area depends on whether the area is inside or outside a TMA. There is no fact type that relates a Restricted Area with a TMA, they are both instances of the Airspace class. However, the business concept of "overlapping geometry" can be included in the business vocabulary of the aeronautical information domain and enables expressing unambiguously such rules.
Thus, a recipe for writing a rule in SBVR could be:
- write the rule in operational terms, trying to identify the main class in the AIXM UML model that is concerned (AirportHeliport, Airspace, Navaid, etc.).
- identify the fact types in the model to which the constraint refers (could be represented as an attribute of a class, an association of a class, or could be a more complex part of the model, involving 2-3 classes and their attributes, indirectly related);
- start building the rule text around that fact type:
- add quantification to each noun concept involved;
- add logical operations, if more conditions are involved;
- add modality for the fact type.
For example:
- "It is obligatory that each Runway isSituatedAt exactly one AirportHeliport
- "It is obligatory that exactly one name is-property-of each AirportHeliport"
Keep in mind that obligations come in two forms in the aeronautical information domain: strict (expressed with "shall") and loose (expressed with "should").
The fact type "is-property-of" is maybe easier to understand if written in the opposite direction using "has/have".
- "Each AirportHeliport shall have exactly one name"
In fact, the two rules mentioned above are already hard-coded in the AIXM UML model and do not actually need to be also defined as AIXM Business Rules.The real goal is to document rules that are not already coded in the UML model. For example, a data consistency rule stating that "a heliport cannot have any associated runway", is defined following the same steps:
- identify in the AIXM UML model the fact types concerned:
- Runway isSituatedAt AirportHeliport
- Runway has type
- AirportHeliport has type
- the model already includes the constraint that the Airport type attribute can get a value from a predefined list: ('AD', 'AH','HP','LS','OTHER'). The value that interests us in this case is 'HP' (heliport). Combining this constraint with the second fact type gives the following: AirportHeliport has type equal-to 'HP'.
- adding modality and quantification gives the following rule: It is prohibited that a Runway has type equal-to 'FATO' and Runway isSituatedAt AirportHeliport and AirportHeliport has type equal-to 'HP'
- in his form, the rule might a bit difficult to understand by domain experts. Therefore, for short rules a simpler form (using the keyword "with") may be used: "Runway with type equal-to 'FATO'" instead of "Runway has type equal-to 'FATO' and Runway..."
- the rule can be written as: "It is prohibited that a Runway with type equal-to 'FATO' isSituatedAt AirportHeliport with type equal-to 'HP'"
It could be argued that the rule can be written more clear in the opposite direction: "Each AirportHeliport with type equal-to 'HP' shall not have associated Runway with type equal-to 'FATO'". However, the fact-type established by the model is that 'Runway is situated at Airport'. All associations in the model have directionality. Therefore, it is better to take this into consideration when writing the rule. In XML, the Runway will point to the AirportHeliport, therefore the rule can be checked directly from the Runway towards the AirportHeliport.