Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.

  • No labels