Features Extension Sub-package

Owned by POROSNICU Eduard
Last updated: 2020 Dec 15

Extending an existing class

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.

The following rules that apply to new extension class:

  • 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).

Adding new classes

In addition, it is possible in extensions to create totally new classes (features and objects), that do not start from existing AIXM core classes. All such new classes, attributes, data types and associations need to follow the rules and conventions defined in the first section of this document: AIXM UML Conventions. This will enable the export script to correctly generate the XML elements for these new classes.

Associations with the Note class

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.

Important Note

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.

Examples

The example to the left 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.


Associations can be created between new or extended classes and AIXM Core features or objects as shown in the example to the left. The new association should be created in the Application Schema package and be navigable towards the AIXM core class (feature or object). It should never be navigable towards a class with <<extension>> stereotype. This action ensures the relationship is represented properly in the XML Schema.

XML Schema Mapping

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.
 

Important Note

The  <extension> element is already declared in the core AIXM Features XSD as multi-occurring, in order to allow for multiple extensions to be used in parallel. Thus, using the AIXM XSD and the extension schema, it is not possible to limit the number of occurrences of an extension to just one. Eventually, this can be limited with business rules.