AIXM Background
The AIXM logical data model is provided in UML and comprises a series of packages and class diagrams. AIXM was developed to be extensible, allowing greater flexibility for international use, in particular to meet individual needs of the AIXM Community of Interest (COI).
Features describe real world entities and are fundamental in AIXM. AIXM features can be concrete and tangible, or abstract and conceptual and can change in time. Features are represented as classes with a stereotype <<feature>>. Examples include Runway, AirportHeliport, etc.
AIXM features are dynamic features. TimeSlice objects are used to describe the changes that affect the AIXM feature over time. TimeSlice objects and temporality are discussed extensively in a separate AIXM Temporality document.
Objects are abstractions of real world entities or, more frequently, of properties of these entities, which do not exist outside of a feature. An object is created for two reasons in AIXM:
- When a property has a multiplicity greater than one (such as the city served by an AirportHeliport), or
- The object has its own attributes that are reused throughout the model, such as is the case for an ElevatedPoint.
Some classes are marked as <<choice>>. These are used to model XOR relationships. For example, an AirspaceVolume's horizontal projection can be a Surface, an AirspaceCorridor or the same shape as for another Airspace.
Properties are the attributes and relationships that characterise a feature or object. In the UML:
- Attributes are used to describe simple properties of a feature or object;
- Relationships are used to describe associations to features or objects. Whenever a property has a multiplicity greater than one, it is described using a UML relationship with cardinality.
- Relationships to objects are depicted by the standard UML composition (aggregation by value) association. Composition is a form of aggregation with strong ownership and coincident lifetime of the parts by the whole. The part is removed when the whole is removed;
- Relationships to features are described with a standard UML association. All the associations are navigable in only one direction. This shows that the two classes are related but only one class "knows" that the relationship exists.
In AIXM, all class properties (both attributes and associations) are optional, in order to enable the encoding of "PERMDELTA" and "TEMPDELTA" TimeSlices. By definition, such TimeSlices contain only the properties that have an actually new/modified/removed value. If any class property was mandatory, then that property would have to be included in any TimeSlice (so that the file is valid against the XSD) even if did not change its values. This would undermine the "delta" encoding principle of the AIXM Temporality Concept.
This rule is hardcoded in the scripts – all properties are generated with minOccurs="0", whatever minimal cardinality the UML model indicates.
The solution for specifying "mandatory" attributes is through Business Rules, which complement the core and extension model. For example the current AIXM set of Business Rules contains rules that are classified as "Minimal data rule".
The UML model lists the datatypes that are used throughout the AIXM. These are given one of the two following stereotypes:
- <<datatype>> This is basic data type that specifies a pattern to use.
- <<codelist>> This is a data type which codes a predefined list of values. The <<codelist>> includes the value OTHER which can be expanded with some free text in uppercase ("OTHER:MY_VALUE") to support un-supported values.
When a property needs to be specified in relation with an association between two classes, a UML association class is used. The association class is attached to the relationship with an Association Class line (as seen in the following diagram).
Inheritance refers to the ability of one class (the specialized or child class) to inherit the properties of another class (the generalized or parent class), and then add new properties of its own. In AIXM, Features must only inherit from other Features and Objects must only inherit from other Objects. Multiple inheritance is not allowed.
Important Note: Inheritance is supported only from "Abstract" classes. The UML to XSD scripts do not support the inheritance from non-Abstract classes, except for derived classes with stereotype <<extension>>, as explained further in this document.
UML Package for Extensions
To extend AIXM, a new package (eventually including sub-packages) must be created under the AIXM Application Schemes package. This package will contain all the information you need for your extension.
The building of an extension and the generation of the supporting XML Schema is illustrated using a fictitious "Test Extension". The Sparx EA file that includes the AIXM 5.1.1 draft version and this[ extension is available |https://drive.google.com/open?id=0BxlGN-YBj-q0WVZzbzJDYmNYSjg]here.
Package Structure
Different types of sub-packages are used to control the generation of appropriate XML schemas (XSD). The example on the right shows the package of the fictitious "TestExtension" used as example, comprising the three sub-packages |
- the "TestExt Features" sub-package contains the extensions to AIXM core <<features>> and/or <<objects>>;
- if the extension requires new data types, then a second sub-package ("TestExt Data Types" in this case) is created, containing any new data types and codelists needed;
- another sub-package that may be needed is the message package ("TestExt Basic Message" in this example). Multiple sub-packages may be required based on the number of different message schemes needed.
The following possibilities for extensions may be applied:
- the most common one - will have the feature package and the data type package. No new message type is created because either the AIXM-BasicMessage is used or because the data is made available through a 'feature service' that does not require a message type.
- feature package only - as a simpler variation of the case a) - no new data types are needed, just additional attributes/associations are needed.
- message package only - when you need to develop a specific message type, for a subset of the existing AIXM features. No new features or data types are created
- all packages
- only data types package, when it is re-used by other extension packages.
Package Specifications and Namespaces
There are several properties that need to be set at package level so the corresponding XSD generation script can generate the namespaces correctly. Below is an example of how these attributes are set for the TestExtFeatures sub-package. In order to define them, please use the "add new tag" menu and its dropdown list. The targetNamespace and targetNamespacePrefix property values are to be determined by the community of interest for which the extension is developed.
Additionally, some custom "AIXM" properties need to be defined, as indicated in the screenshot below. The generateFileName property indicates that file name of the XSD that is output from the package. The fileLocation property defines the relative location where the extension will be stored (this property allows the script to correctly generate the reverse links to the AIXM XSD files inside the extension XSD files. e.g. "../../AIXM_Features.xsd")
Finally, in order to correctly generate the necessary import/include statements, the Links between the packages have to be specified, as shown in this example for the TestExtFeatures package:
This dependency is also visible in the features package properties:
Note that the import statements for the gml and xlink namespaces are generated by default. The following import statements is included by default in any extension file:
<import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"/>
<import namespace="http://www.w3.org/1999/xlink" schemaLocation="http://www.w3.org/1999/xlink.xsd"/>
The eventual import of the aixm namespace has to be declared explicitly, as a package import (as shown on the previous package diagram).
The following was generated for the fictitious Extension Application Schema package. The extension data types include statement is generated based on the schema dependency.
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:aixm="http://www.aixm.aero/schema/5.1.1" xmlns:testext="http://www.aixm.aero/schema/5.1.1/extensions/test" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.aixm.aero/schema/5.1.1/extensions/test" elementFormDefault="qualified" attributeFormDefault="unqualified" version="5.1.1.a">
<import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"/>
<import namespace="http://www.w3.org/1999/xlink" schemaLocation="http://www.w3.org/1999/xlink.xsd"/>
<import namespace="http://www.aixm.aero/schema/5.1.1" schemaLocation="../../AIXM_Features.xsd"/>
<include schemaLocation="./TestExt_DataTypes.xsd"/>
Features Extension Sub-package
Overview
An AIXM class with <<feature>> or <<object>> stereotype may be extended by creating a class with the same name as the core AIXM class and giving it a stereotype <<extension>>. This new class can contain:
- New attributes
- New associations.
Some rules that apply to new extension classes are:
- The extension class stereotype must be <<extension>>;
- The extension class name for the extension must match the class that is extended;
- The extension class must be a specialized class extending the matching base class, i.e. if a core AIXM class is involved, the navigability of the association should always be from the <<extension>> class towards the core AIXM class.
- The extension class attributes are added to the extension class the same as they would be a regular AIXM class (Data Types are discussed later in this document).
The example to the right shows the modeling convention used to extend the core AIXM AirspaceActivation feature.
The example adds a new attribute to AirspaceActivation and a new relationship to a new object called TestObject.
In addition, it is possible in extensions to create totally new classes (features and objects), that do not extend existing AIXM Core classes.
The only rule is to follow the AIXM UML modeling conventions described at the beginning of the document. This will enable the EA export script to correctly generate the XML elements for these new classes. This situation is not described in detail in this document because it does not require any special action. Just follow the UML modeling conventions.
Associations can be created between new features or objects and AIXM Core features or objects as depicted below in the association between the RouteAvailability and the Airspace feature. The new association should be created in the Application Schema package and towards the AIXM Core Feature rather than an extension (if present). This action ensures the relationship is represented properly in the XML Schema.
Concerning annotations/remarks, the core AIXM model includes as dedicated <<object>> named Note. This is associated with all the classes defined in the AIXM model. It is recommended that each <<object>> or <<feature>> class created in an extension is also associated with the Note class of AIXM. This gives the possibility to add remarks, descriptions and other such free text notes in relation of extended features or properties.
Attention: it does not make sense to add the association to Note from the <<extension>> classes! That's because an <<extension>> class does not create a new feature or object. It just adds properties to an existing AIXM class, which already has the association to Note. The XSD generation script will even ignore such associations.
XML Schema Generation
Use the EA export script to generate the extension XML Schema in which the script triggers the generation of an extension element by recognizing the <<extension>> stereotype. Generation of the extension follows the AIXM generation rules.
Operating system and configuration
The script provided is configured for Windows XP systems and it includes a Java runtime engine. For other Windows versions, make sure that the Sparx Systems\EA\Java API is included in the windows Path, as shown below:
PATH = ./jre/bin/;C:\Program Files (x86)\Sparx Systems\EA\Java APIjava -cp ./resources/eaapi.jar;./resources/jxl.jar;./bin/ eurocontrol.swim.model.ATM_Data_Models_Processing_Toolpause
Executing the Script
There are some specific options that need to be set when executing the EA script, but most of the options will be defaulted. The schema generation scripts are used for both AIXM Core and Application Schemas.
Known issues and limitations of the scripts are documented in Appendix 1.
Execute the 'start.bat' file of the 'step1 – EA export script'. This will open the following dialog window.
To load the UML model, i.e. the .eap file, click on the '...' button and drill down to the file location where you have the eap file.
Next, click on the 'AIRM' button. Then, click on the 'Load UML model' button.
When finished, the Console will show 'Loading complete…'.
Next, select the checkbox that you want to generate from the list of available Physical Models.
On the next screen, you can select/unselect the checkbox to 'Include documentation'. If you select the checkbox, it will generate out the annotation(s) in the XSD file from the UML diagrams' Notes section(s).
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="bc0e8a77-e181-4338-8d33-d11ad99f7328"><ac:plain-text-body><![CDATA[ | Check '[AIXM 5.1 Extension] XML SCHEMAS GENERATION - Generate Extension Features Schema' then press the 'Apply' button and select the package to be processed. |
Additional step - order of associations
Note that an additional step might be required: re-order the XML extension properties (child elements) that correspond to associations in the UML model so that they appear in the same sequence as in the previous version of the extension(if applicable). The problem is that the EA export script has no control on the order in which these properties are generated in the XSD extension schema.
Therefore, they need to be re-ordered looking at the previous version of the extension XSD.This can be done with[ the XSLT script|https://drive.google.com/file/d/0BxlGN-YBj-q0NXl1VFNrdVlmMTg/edit?usp=sharing] provided for the core model. The scripts include the name of the AIXM 5.1 XSD reference file (see "AIXM_Features-5.1.xsd" on lines 78 and 79). In order to run the script on an extension schema, the reference schema file name needs to be replaced with the name of the extension reference schema (such as "MyPreviousExtension_Features_reference.xsd", for example).
The script takes as input the newly generated "features" extension XSD and the previous "reference" version. For those properties that have an identical name, the script re-arranges them in the same sequence that they were arranged in the previous XSD. Any new properties are listed at the end. Any missing properties are ignored.
Note: the script might not work correctly if the reference XSD uses the "xsd:" prefix for schema elements, such as xsd:sequence or xsd:choice. To solve this problem, the "xsd:" prefix needs to be removed from all the elements in the reference schema (with a simple text editor, using replace all).
XML Schema Output
Classes with the stereotype of <<extension>> generate three related elements for that class.
- <classname>ExtensionPropertyGroup
- <classname>ExtensionType
- <classname>Extension
The <classname>ExtensionProperyGroup contains the properties (elements and relationships) of the Extension.
The <classname>ExtensionType element is generated as a XMLSchema <complexType.> and extends base type aixm:AbstractExtensionType.
The <classname>Extension element is generated as a XMLSchema <element>. The Extension element cannot stand alone, it may only exist as an extension to an AIXM base element. The Extension element does not have a timeslice. The Extension element attribute substitutionGroup is the substitutionGroup of the base type extension. Extension elements are not extensible.
The <classname>Extension element is generated as a XMLSchema <element>. The Extension element cannot stand alone, it may only exist as an extension to an AIXM base element. The Extension element does not have a timeslice. The Extension element attribute substitutionGroup is the substitutionGroup of the base type extension. Extension elements are not extensible.
All Features Extension
Sometimes it is necessary to create a similar extension for all AIXM features of the core model. This section explains how such an extension can be defined and instantiated.
In order to not have conflicts in the generation of the Extension types, it is not possible to use both the "all features extension" and the extension of an individual class in the same extension. They need to be separated and have separate namespaces.
See the example below for how an extension is created to all AIXM Feature Timeslices, by declaring an extension of the AIXMTimeSlice. This should be propagated by the script to all SomeFeatureTimeslice.
Data Type Extension Sub-package
Overview
An extension, new feature or object class may require additional data types or codelists to capture the valid values for new attributes added to the class.
To add new data types or codelists create a Data Type sub-package containing any new data types needed.
In the example below, a <<codelist>> is defined in an extension package. It is called TestCodeList, it has a generalization to the 'string' class and inherits the basic attributes of an XSD string variable (from the XMLSchemaDatatypes, which is separate package in the AIXM UML model).
The <<datatype>> TestDataType is created with the nilReason property, of type NilReasonEnumeration (from the ISO 19136 UML package, included in the AIXM UML model). This is the most common configuration for codelists.
AIXM Core <<codelists>> can also be extended in the Data Type sub-package. Extend a codelist by creating a class with the same name as the codelist and giving it a stereotype <<codelist>>.
Careful analysis must be done to ensure that the extended list of values remains normalised. It shall not duplicate values that already exist in the core <<codelist>> (including the OTHER value), but with other names/abbreviations.
Another example is the creation of a new data type that is constrained by a pattern, as presented in the diagram at the right of the page.
The pattern and whiteSpace values are declared as "initial values" in Sparx EA and the attributes themselves need to be declared with stereotype <<XSDfacet>>, as shown in the screenshot below:
Patterns are encoded using regular expressions. The Schema Recommendation suggests that an XML validator should implement "Level 1" regular expressions as defined in the[ |http://unicode.org/unicode/reports/tr18/]Unicode Regular Expression Guidelines.
XML Schema regular expressions are similar to other well-known regular expressions, such as might be found in UNIX or Perl.
XML Schema Generation
Use the step 1 - EA export script to generate the data type extension XML Schema. Follow the procedures outlined in section 2.2.2.2.
Data Types are generated as a XMLSchema <simpleType> with the appropriate facets, Patterns and/or codelists defined.
The AIXM UML Model, in more details
Diagram types
Two types of diagrams are used in the model:
- Class diagrams – Used to represent the features, properties, relationships and inheritance between features;
- Package diagrams – Used to split the model into modules and identify dependencies among sets of classes.
Stereotypes
The classes are distinguished by their stereotypes. Stereotypes are used to further define and extend standard UML concepts. The main stereotype are <<feature>>, <<object>>, <<choice>>, <<datatype>> and <<codelist>>.
Abstract Classes
In addition, some classes are abstract. Abstract classes are designated by putting the class name in italics. An abstract class cannot be realised in an implementation such as an XML document. Instead, abstract classes are used as base classes in an inheritance hierarchy. For example, the AIXMFeature abstract class describes the basic properties of an AIXM Feature. Every specific AIXM Feature, such as Runway, inherits Please see section 3.1 The Abstract Model, which explains why this inheritance is not visible in UML from the abstract AIXMFeature class.
Features
Features describe real world entities and are fundamental in AIXM. AIXM features can be concrete and tangible, or abstract and conceptual and can change in time. Features are represented as classes with a stereotype <<feature>>. Examples include Runway and AirportHeliport.
AIXM features are dynamic features. Timeslice objects are used to describe the changes that affect the AIXM feature over time. Timeslice objects and temporality are discussed extensively in a separate AIXM Temporality document.
Objects
Objects are abstractions of real world entities or, more frequently, of properties of these entities, which do not exist outside of a feature. An object is created for two reasons in AIXM:
- When a property has a multiplicity greater than one (such as the city served by an AirportHeliport), or
- The object has its own attributes that are reused throughout the model, such as ElevatedPoint.
In both cases, the property is represented as an object with the proper UML composition relationship as shown below.
Choice
Some classes are marked as <<choice>>. These are used to model XOR relationships. For example, the length of a Holding Pattern can be expressed using a HoldingPatternDistance, a HoldingPatternDuration or a SegmentPoint defining the end of the outbound leg.
Properties
Properties are the attributes and relationships that characterise a feature or object. In the UML:
- Attributes are used to describe simple properties of a feature or object;
- Relationships are used to describe associations to features or objects. Whenever a property has a multiplicity greater than one, it is described using a UML relationship with cardinality.
Attributes
Simple properties of cardinality one are shown as attributes in the UML diagram.
An attribute has the following format:
Visibility / stereotype name : type multiplicity
For AIXM 5 the following values are used:
- Visibility – Public
- / – not used
- Stereotype – not used
- Name – name of the property
- Type – property type
Multiplicity – usually not specified; for reasons related to the AIXM Temporality model, an implementation should assume that all properties are optional, \[0..1\]
To illustrate, the Runway feature has several simple properties e.g. designator and type. These properties are assigned a datatype; for example, the designator attribute is of type TextDesignatorType.
DataTypes
The UML model lists the datatypes that are used throughout the AIXM. These are given one of the two following stereotypes:
- <<datatype>> - This is basic data type that specifies a pattern to use.
- <<codelist>> - This is a data type which codes a predefined list of values. The <<codelist>> includes the value OTHER which can be expanded with some free text in uppercase ("OTHER:MY_VALUE") to support un-supported values.
All the data types used to type AIXM simple properties define a nilReason, which is used to indicate the reason for a null value. This is realized in AIXM 5.1 by introducing
- A base type, which contains the core "business" information, such as a range of value for <<datatype>>, or the list of string values for <<codelist>>
- A derived data type, which explicitly declares the nilReason attribute, and which is used to type the corresponding AIXM simple properties.
On the example above, the base type used to represent an angle is named ValAngle{*}BaseType{*}. It derives from decimal and defines the range of values allowed for an angle percentage (\[-180;180\]). The derived datatype ValAngle{*}Type* inherits from ValAngleBaseType and includes the nilReason, typed with NilReasonEnumeration. ValAngle{*}Type* is always used to type the percentages specified in AIXM features or AIXM objects.
A limited set of data types defined in the AIXM 5.1 UML model are not used to type directly AIXM simple properties but are basic classes from which several AIXM data types inherit. These data types are: AlphaType, AlphaNumericType, Character1, Character2, Character3. They do not require a nilReason attribute, and consequently, no corresponding BaseType types are defined in the AIXM UML model.
In addition, certain <<datatype>> might have an associated Unit Of Measurement. This is indicated in the model by the inclusion of a "uom" attribute at the same level as the nilReason attribure, i.e in the definition of the derived <<datatype>> class. The type of the uom attribute is typically a <<codelist>> class, as shown below:
Note that the <<codelist>> types representing Units of Measurement do not require a nilReason. As a consequence, no base type is created for uom.
Relationships
Whenever a property has a multiplicity greater than one, it can not be described in UML with an attribute. In that case, the property is described using a UML relationship which specifies the cardinality and which is always navigable in one and only one direction. The name of the complex property is given by the name of the role played by the targeted class.
Relationships to Objects
Relationships to objects are depicted by the standard UML composition (aggregation by value) association. Composition is a form of aggregation with strong ownership and coincident lifetime of the parts by the whole. The part is removed when the whole is removed.
The example above shows that the <<feature>> Runway has a property named theSurface. This property is modelled in UML using a composition association between the <<feature>> Runway and an object representing the characteristics of a geometric surface.
Relationships to Features
Relationships to features are described with a standard UML association. All of the associations are navigable in only one direction. This shows that the two classes are related but only one class knows that the relationship exists. In the example below the Runway feature knows about the AirportHeliport but the AirportHeliport does not know about the Runway.
Association Classes
When information about a relationship is required, a UML association class is used. The association class is attached to the relationship with a dotted line.
Inheritance
Inheritance refers to the ability of one class (the specialized or child class) to inherit the properties of another class (the generalized or parent class), and then add new properties of its own. In AIXM, Features must only inherit from other Features and Objects must only inherit from other Objects. Multiple inheritance is not allowed.
In the example below the VOR is a kind of NavaidEquipment.
Naming
Feature, Object and Choice names are written in UpperCamelCase e.g. NavaidEquipment.
Simple property names (i.e. attributes) are written in lowerCamelCase e.g. widthShoulder. Relationship names are written in lowerCamelCase but as present tense verbs e.g. isSituatedAt. Relationship Role names are also written in lowerCamelCase and they are nouns that express the role played by the class in the association.
Datatype names are written in UpperCamelCase and end with 'Type' e.g. CodeAircraftType.
Other Aspects of the Model
To simplify the UML model some convenience steps have been taken. Some elements are not shown on every diagram and some relationships are 'assumed'.
The Abstract Model
The model should contain a set of abstract AIXM classes that are used as the building blocks for the AIXM XML Schema. However, for simplicity, these relationships are not shown on any diagram and do not really exist in the UML. They are just assumed to exist, when converting from the UML model to the XML Schema of AIXM.
AIXMFeature and AIXMFeatureTimeSlice Class
The UML below shows how each and every <<feature>> inherits from the abstract AIXMFeature class. The concrete features are described by TimeSlices which are composed of properties. The TimeSlice inherits from the abstract AIXMFeatureTimeSlice class.
The diagram above is quite complex. If applied to the whole set of AIXM classes, it might undermine the readability of the UML diagrams. Therefore, the Design Team has decided to provide a simplified UML model, without visible inheritance of all features from the abstract AIXMFeature and without visible SomeFeatureTimeSlice classes.
However, all of these relationships and classes must be mapped in the AIXM XML Schema.
Metadata
The diagram also shows that each AIXM Feature and each TimeSlice is described by metadata. The AIXM XML schema incorporates the ISO 19139 metadata elements - see 3.2.2.
Extension
Finally, each TimeSlice may contain an Extension. The Extension mechanism allows each user of AIXM5 to define and use his own specific attributes and classes.
External packages
<<XSDschema>> XMLSchemaDatatypes
The XSD Schema Datatypes package declares XSD specific data types that are referenced by AIXM data types, when generating the AIXM XML (XSD) Schema. However, these XSD bindings do not mean that AIXM is "dependent" on the XML Schema specification. The pre-defined XSD simple types (such as string, decimal, unsignedInt, etc.) referenced by AIXM are sufficiently generic and mappable to the simple data types of many other data encoding standards.
ISO 19115 Metadata
This package contains some basic connections from the AIXM model to the ISO 19115 Metadata elements (MD_Metadata, MD_Constraints …).
ISO 19107 Geometry
This package contains some basic connections from the AIXM model to the ISO 19107 geometry elements (GM_Point, GM_Surface …).
ISO 19136
This package contains some basic connections from the AIXM model to GML specific elements, which are not part of the ISO 19107. Practically, the package contains only the data type NilReasonEnumeration, used to indicate the reason for a null value.