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.