Page Comparison

Concept

SBVR Definition:

• Unit of knowledge created by a unique combination of characteristics.
  
  Representation in profile:
• Not represented – too general

NounConcept

Verb-concept
also known as
"Fact type"

Name

keyword

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.
Note that the separator is also formatted, just to keep the editing simple, although it is not part of respective noun concept.

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.
When the NounConcept is in the target association class or beyond, the path includes first the name of the association role, concatenated with the association class name, then the name of a fictitious theMyClass property name followed by the target class name. For example: geometryComponent.AirspaceGeometryComponent.theAirspaceVolume.AirspaceVolume.lowerLimit.

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…".
When there is no risk for

confusion, 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 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:

• interpretation
• sequenceNumber
• correctionNumber
• validTime
• featureLifeime
  Note: in order to avoid confusions, these properties appear in the SBVR formulation as properties of timeSlice.AIXM Feature TimeSlice.

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:

• ….Curve.segments.GeodesicString

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.

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

• "has" as fact type for the attributes of a class: there is an implicit association (fact type) between a class and each of its attributes. This can be expressed using both the is property of or the has fact type (depending on direction in which the rule is written). For example: "name is property of AirportHeliport" or "Airspace has type"
• "has" as fact type for the properties of an associated <<object>> class: The AIXM UML model makes a difference between <<feature>> and <<object>> classes (stereotype). An <<object>> is seen as a complex property of another class. Therefore, "has" can be used as a simplified fact-type in situation such as the following:
  
  • Airspace has geometryComponent.AirspaceVolume.upperLimit ("has" followed by the role name of the target class is used instead of the feature-object association name "hasGeometry")
  • AirportHeliport has servedCity.City.name ("has" followed by the role name of the target class is used instead of the feature-object association name "serves")
    
    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:
  • Runway isSituatedAt AirportHeliport (this cannot be replaced by "Runway has associatedAirportHeliport.AirportHeliport"!)

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)
or
contextualisation fact type

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 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

The following equivalent formulation is sometimes used in this profile in order to improve the readability of the text:

"Each… shall…"

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.

quantifier
name

SBVR Profile for ATM Representation

logic
symbol

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
(n ≥ 1)

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..
(n ≥ 1)

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..
(n = 2)

There is at least 2 x.

exactly-n

exactly n x

∃n
(n ≥ 1)

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
(n ≥ 1)
(m ≥ 2)

There is at least n and at most m x

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:
assigned noun-concept value

with

has fact type plus a condition on the property or descendant

used as a simplified form of:
p has q and q …some condition for q...

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
... p… some condition for p… that verb q … some condition for q …

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