Naming Convention

Class names are written in UpperCamelCase notation,  e.g. NavaidEquipment.

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

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. 

Abstract classes and inheritance

Some classes are "abstract" and they have their class name written in italics on the class diagrams. 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.

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.

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. 

Attributes

Attribute names are written in lowerCamelCase notation, e.g. widthShoulder.

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.
 


  • No labels