or AirportHeliport” type” is property of has “name “Airspace as fact type for the properties of an associated <<object>> “has” The AIXM UML model makes a difference between class: <<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 servedCity.City.name (“has” followed has 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 AirportHeliport (this cannot be isSituatedAt replaced by has “Runway associatedAirportHeliport.AirportHeliport”!) describes a deeper associative fact than an instance of the is-descendant-of “is-property-of”; first concept constitutes a property of a property (and so on…) of an instance of the second concept describes the same associative fact as but in the opposite has descendant “is-descendant-of”, direction categorisation fact type (used to target a specific non-abstract class, that is a specialisation specialisation of a parent class; for example NavaidEquipment VOR) specialisation or contextualisation fact type a particular instance of the concept is also an instance of the category categorization* is used for expressing units of measurements (UOM) is-of-type* Logical Operations The following table introduces the logical operations (e.g. etc.) used in the SBVR Profile “and”, ”not”, “or”, for AIXM. The exact representation of the operations is in the third column (using keywords convention).
“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 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 third column (using keywords convention).
aixm5.1-businessrules-usingsbvrandschematron-ver0.7.docx