AIXM 5.1 - Business rules (data verification)
Using SBVR and Schematron
How to provide comments:
comments/suggestions for the improvement of this document should be made directly on the original version available in GoogleDocs. Please ask for access by sending an e-mail to
Document Status: Draft
Publication date: 09 June 2014
version: 0.3
Aeronautical Information Exchange Model
(AIXM)
Copyright: 2014 - EUROCONTROL and Federal Aviation Administration
All rights reserved.
This document and/or its content can be downloaded, printed and copied in whole or in part, provided that the above copyright notice and this condition is retained for each such copy.
For all inquiries, please contact:
Diana YOUNG –
Eduard POROSNICU -
Edition / Status / Issue Date / Reason for Change0.1 / Working Draft / 25 JUL 2013 / Initial working draft. Derived from previous work by Pulsar Consulting (under contract for Eurocontrol) and from the “Guidance on Writing AIRM Constraints” - SESAR Project 08.01.03 deliverable, which is itself based on the previous Eurocontrol work
0.2 / Working Draft / 05 AUG 2013 / Updated after initial attempts to use the instructions and after discussion with group members, in particular issues raised by Michal Kadlec
0.3 / Draft / 09 June 2014 / First public release, intended for a wider review. Also including an introductory part explaining the need for business rules, the experience of the previous AIXM model version and the approach proposed for AIXM 5
Contributors
This document is the result of consultation with many specialists, in particular from industry. Their contribution is hereby acknowledged.
Note: this list might be incomplete, please do not hesitate to bring any omissions to the attention of the document editor!
Name / OrganisationCHUMAKOV Marina / CNA (under contract for US FAA)
DRUARD Sophie / Pulsar Consulting
FABBRI Davide / IDS
GERMAIN Francois / Thales
GROBSCH Volker / MClick
HAAS Markus / Comsoft
d’HULST Jean-Christophe / Pulsar Consulting
KADLEC Michal / Avitech
POROSNICU Eduard (editor) / Eurocontrol
RAZOV Aleksandr / Monitor Soft
SANCHEZ Antonio / GroupEAD
SCHEIDER Markus / MClick
SUZIC Robert / Eurocontrol
TANG Yauwu / MITRE Corporation
WALTL Michael / Frequentis
WILSON Scott / Eurocontrol
Table of contents
Contents
Executive Summary 5
1 Introduction 6
1.1 The need for Business Rules 6
1.2 How to read this document 6
2 Rules definition using SBVR 7
2.1 Introduction 7
2.2 SBVR Profile for AIXM 7
2.2.1 SBVR concepts 7
2.2.2 Logical Operations 9
2.2.3 Quantification 10
2.2.4 Modality 11
2.2.5 Additional SBVR keywords 11
2.2.6 Additional Fact-types 12
2.3 Methodology 12
3 Schematron reference implementation 15
3.1 Introduction 15
3.2 Schematron code - technical aspects 15
3.2.1 XPath version 15
3.2.2 Use of Java extensions 15
3.2.3 Content of the Excel file 15
3.2.4 Practical verification of AIXM data sets 16
3.2.5 Testing 16
4 AIXM Business Rules data set 17
4.1 Excel file 17
4.2 Profiles 17
4.2.1 EAD Data Provider 17
4.2.2 Minimum air navigation data set profile 17
4.2.3 Full air navigation data set profile 17
4.2.4 Digital NOTAM profile 17
5 References 19
Annex A - License and Disclaimer 20
Annex B - Examples 21
Executive Summary
This document defines the AIXM 5.1 approach for modelling to “business rules” - how they are modelled and how they are provided. Such rules can be used to verify if AIXM XML data sets that are syntactically valid (against the AIXM XML Schema) are also semantically correct and can be used in confidence for a particular application.
The AIXM set of business rules provided with this document is intended as a general-purpose collection of rules. Only a subset of these rules might be relevant and need to be enforced/checked for a particular application, eventually complemented with additional rules that are important for that application. For example, a rule that concerns mandatory feature properties indicates that the frequency of a navaid is a required value. While for a charting or air navigation support application this is a necessary constraint, for a flight planning application this is not necessary. Therefore, profiles of this general-purpose set of AIXM business rules will be proposed for particular applications and/or AIXM user communities.
The Semantics of Business Vocabulary and Business Rules (SBVR) [1] standard is applied for writing the AIXM business rules, in relation with the AIXM UML logical data model. This document provides 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. This document is not intended as an exhaustive introduction in SBVR; it is mostly a “primer” document, giving the essential elements that need to be understood in order to:
● contribute to the writing of the AIXM 5.1 Business Rules in compliance with the SBVR methodology;
● read and understand the AIXM 5.1 Business Rules by those interested to review and/or implement such rules in a given system.
In addition to the SBVR definition, the general-purpose set of AIXM Business Rules provided with this document also includes a Schematron [4] encoding of most of these rules. This is done for two reasons:
● in order to verify that the SBVR description of the rule is sufficiently clear and unambiguous in order permit its actual implementation as software code;
● to offer practical means by which an AIXM data set could be verified against the business rules, using software readily-available on the Web, most of it for free.
However, it shall be kept in mind that this Schematron encoding is missing for some rules for which the encoding is expected to be very complex or even impossible. In addition, any use of the Schematron coding provided with the AIXM Business Rules is subject to the license and disclaimer copied in Annex A.
1 Introduction
1.1 The need for Business Rules
The Semantics of Business Vocabulary and Business Rules (SBVR) [1] standard defines business rules as being “a law or principle that operates within a particular sphere of knowledge, describing, or prescribing what is possible or allowable” and that is also under the jurisdiction of a particular business. In the AIXM case, that jurisdiction is the aeronautical information domain. The aim of defining the AIXM Business Rules is to describe what is possible or allowed in an AIXM data set, in particular with regard to data values.
The AIXM UML model defines the information items that are in the scope of the “aeronautical information” domain using UML class diagrams. This includes definitions for classes, attributes and associations between classes. For attributes, the constraints expressed as lists of values, range of values, pattern are also included in the AIXM UML model.
The AIXM XML schema is derived from the UML model and defines elements that correspond to the AIXM model classes, attributes and association role names. The values of XML elements and data types derived from UML attributes are constrained based on the data types defined in the UML model - list of values, data ranges and/or patterns.
More complex constraints, such as dependencies between the values of different attributes (sometimes in different classes), detection of ‘out of range’ values, mandatory properties for class of objects, etc. are not included in the UML model and do not appear in the XML Schema. Thus the need to document such more complex constraints as “business rules”.
Not all the AIXM Business Rules defined in this document are equally applicable in all communities of AIXM users. The most obvious examples are mandatory properties for AIXM features - in a flight planning community, there is no need to include in an AIXM data set the frequency/channel of a navigation aid. On the other side, such attributes are mandatory for data sets provided to an air navigation community. Therefore, the aim of this document is to document the largest possible set of candidate AIXM business rules, from which profiles for a particular community can be extracted.
1.2 How to read this document
Operational/domain experts are recommended to read the Executive Summary, the Introduction and Rules definition using SBVR (in particular the Methodology section). Then, go directly to the AIXM Business Rules data set chapter.
The Schematron reference implementation chapter is intended for developers. However, it should be kept in mind that the use of Schematron is not the only option available for the implementation of the AIXM 5.1 business rules. The Schematron code will provided where possible (as an estimation, for 80% of the rules) as an example only.
2 Rules definition using SBVR
2.1 Introduction
The Semantics of Business Vocabulary and Business Rules (SBVR) [1] standard is used for the writing of the AIXM business rules in relation with the AIXM UML logical data model. 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. The content of this document and the AIXM-SBVR profile is based on:
● previous work done by Pulsar Consulting, under contract for Eurocontrol, which is available on the AIXM wiki: Use of SBVR for AIXM [2];
● Guidance on Writing AIRM Constraints [3] provided by SESAR Project 08.01.03.
This document is not intended as an exhaustive introduction to SBVR. Apart from reading the full SBVR specification [1], the following ‘SBVR essential” reading list is suggested:
● the first pages in Chapter 10 of the OMG SBVR specification [1] version 1.1;
● this presentation available in the Web (in particular slides 5 and 6):
2.2 SBVR Profile for AIXM
2.2.1 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 (such as Microsoft Excel) for the provision of the AIXM set of Business Rules.
Concept / SBVR Definition:● Unit of knowledge created by a unique combination of characteristics.
Representation in profile:
● Not represented – too general
NounConcept / SBVR Definition:
● Concept that is the meaning of a noun or noun phrase.
Representation in profile (i.e. what AIXM items may appear as NounConcept according to the SBVR profile):
● Represented by AIXM UML Classes and Properties, meaning that AIXM Class Name, Role Name or Attribute Name may appear as NounConcept.
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.
Colour: #008080
Example: AirportHeliport, Airspace.type, AirportHeliport.name, Runway.associatedAirportHeliport (note that the separator dot is also formatted, just to keep the editing simple, although it is not part of same the noun concept)
Verb-concept
also known as
“Fact type” / SBVR Definition:
● Concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities.
Fact is a proposition that is taken as true.
Fact-type> :: = <concept1> <verb> <concept2>
Verb Concepts:
● Business Facts
● Relations amongst Concepts
Representation in profile (i.e. what AIXM items may appear as Verb-concept according to the SBVR profile):
● Represented by Name of AIXM UML association.Some frequently used fact types such as “name is property of AirportHeliport” or “Airspace has type”do not appear explicitly in the model, they are implicit associations between a class and one of its attributes. therefore, they are declared by the profile itself as “additional-fact-types”..
Style: italic
Colour: #0000ff
Example: AirportHeliport has name, Runway hasSurfaceDescribedBy SurfaceCharacetistics.
Name / SBVR Definition:
● Name is concept that corresponds to only one object [thing] used for the designation of an individual concept — a name. Names tend to be proper nouns.
Representation in profile (i.e. what AIXM items may appear as Name according to the SBVR profile):
● Represents UML Instances, Slots, Enumeration literals, and their assigned Properties
● CodeList values
Style: surrounded by ‘simple quotes’
Colour: #339966
Example: ‘Sweden’, ‘CTA’, ‘CTA_P’, ‘YES’, ‘NIL’
Note that ‘NIL’ is an additional Name concept used in the SBVR profile for AIXM. It indicates a void property (i.e. a property that does not have a value).
Note: Sometimes, it is necessary to provide a “list of names” (such as ‘A’, ‘B’ or ‘C’) in order to indicate the allowed values for a property (which appears as a NounConcept in SBVR rules). The following style shall be used: opening-bracket, followed by each Name-value surrounded by simple quotes, separated by comma and ending with closing-bracket.
Example: (‘A’,‘B’,‘C’) (note that the quotes and the brackets are also formatted, just to keep the editing simple)
keyword / SBVR Definition
● are used to construct statements – the words that can be combined with other designations to form statements and definitions, see sections on Logical Operations, Quantification, Modality and Additional SBVR keywords, all these being part of the keyword concept.
Representation in profile:
● No particular mapping to UML model elements
Style: Usual text format
Colour: #ff9900
Example: Each - referring to universal quantifier.
2.2.2 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).
Note: 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 / Meaningconjunction / 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.
2.2.3 Quantification
The following table introduces the quantifications (e.g. “at least one”) used as part of the SBVR Profile for AIXM. The third column contains the representation (using keywords convention).