AIXM 5 UML Modelling Conventions
AIXM is GML AIXM is an XML exchange standard based on a subset of GML. Essentially: AIXM Features are GML features AIXM Objects are GML objects AIXM follows the GML object-property concept
Diagrams Model uses: Class diagrams Package diagrams features, properties, relationships and inheritance between features Package diagrams split the model into modules and identify dependencies among sets of classes.
Stereotypes Stereotypes are used to further define and extend standard UML concepts. <<feature>> <<object>> <<choice>> <<datatype>> <<enumeration>> <<codelist>>
Abstract Classes 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 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 from the abstract AIXMFeature class.
Features Real World Fundamental objects Change in time stereotype In AIXM features describe real world entities and are the fundamental objects used in GML. GML features can be concrete and tangible, or abstract and conceptual and can change in time. Features are represented as classes with a stereotype <<feature>>. Features and Objects are described using the “class” structure in an UML class diagram. The class structure is broken in two parts; the attribute list used to define more specifics about the Feature/Object and the Operations list which is not used in AIXM. Feature/Objects are written in UpperCamelCase.
Objects The object has its own attributes that are reused throughout the model A property has a multiplicity greater than one In AIXM objects are abstractions of real world entities that do not exist outside of a feature. Whenever a property has a multiplicity greater than one and cannot exist outside the feature these properties are represented as an object with the proper UML composite relationship ElevatedPoint shows the second use if objects – when it has its own attributes and is reused throughout the model
Choice Used to model XOR relationships Choice elements are modelled using XSD choice elements.
DataTypes Datatypes are used throughout the model <<datatype>> – basic data type that specifies a pattern to use <<enumeration>> – a fixed list of values <<codelist>> – similar to an enumeration but the list can be expanded The OTHER value is important for mapping future changes to the list. If a value is added in the future and is not recognised by the current enumeration, it is mapped to the OTHER value
Properties - Attributes Attributes are used to describe simple properties of a feature or object Simple Properties Properties are the attributes and relationships of a feature or object that are used to characterize the object. In UML attributes are used to describe simple properties with a cardinality of one. Attributes are written in lowerCamelCase.
Properties - Relationships Relationships are used to describe associations to features or objects Uni-directional association used when the relationship refers to a feature Relationships to objects are depicted by the standard UML composition Relationships are used to describe associations to features and objects. Whenever a property has a multiplicity greater than one it is described using a UML relationship with cardinality. AIXM uses only 4 of the UML modelling techniques provided for class diagrams. Uni-directional association shows that two classes are related but only one class knows that the relationship exists. In our first example the Runway features knows about the AirportHeliport feature. AirportHeliport knows nothing about the Runway. Composition Aggregation. Basic aggregation is an association indicating that one class is a subordinate (or part of) another class, however, the child class can outlive the parent class. A composition Aggregation indicates the same parent-child relationship but the child’s lifecycle is dependent on the parent. In other words the child can not exist without the parent. In our example a Runway has a surface. When the Runway no longer exists, neither does the surface.
Properties - Relationships Standard UML association class is used to describe attributes about the relationship The third modelling technique is the standard UML association class. In modeling an association, there are times when we need to include valuable information about the relationship. For this we would use an association class that you tie to the primary association. An association class is represented like a normal class. The difference is that the association line between the primary classes intersects a dotted line connected to the association class.. The uni-directional arrow is important when mapping to the XSD. One important attribute shown is the collocationGroup describing how the navaid is composed of different equipment. In this case, what equipment is located together.
Properties - Inheritance Inheritance - The specialized feature inherits all of the properties of the more general feature The last technique used is inheritance. Inheritance refers to the ability of one class (specialized or child class) to inherit the identical functionality of another class (generalized or super class), and then add new functionality of its own. Within our XML schema, specialization implies two characteristics: Substitutability. The more general feature or object can be substituted by a specialization. In the XML schema this is supported using substitution groups. Property inheritance. The specialized feature inherits all of the properties of the more general feature. In the XML schema including the properties of the general class into the specialized class supports this. NavaidEquipment is shown as abstract and not implemented in the XML schema. The VOR feature is implemented inheriting the attributes of NavaidEquipment.
Naming Conventions 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 Datatype names are written in UpperCamelCase and end with ‘Type’ e.g. CodeAircraftType
Thank you