1
03 August 2011
Edition 00.00.01
AIRM Guide For Managers
Understanding the AIRM
Executive Summary
This guide provides overview information and practical guidance for managers and
readers of the AIRM Models. The guide is intended to be informative and is
focused on supporting the understanding of information models in a way that does
not require deep (technical) modelling knowledge and skills.
Project ID 08.01.03.
Project ID 08.01.03.
AIRM Guide For Managers
Table of Contents
1
INTRODUCTION.......................................................................................................................................... 3
1.1
SCOPE AND APPLICATION ....................................................................................................................... 3
1.2
INTENDED READERSHIP .......................................................................................................................... 3
1.3
ACRONYMS AND TERMINOLOGY ............................................................................................................. 3
1.4
ADOPTION ............................................................................................................................................... 3
1.4.1
Normative ...................................................................................................................................... 3
1.4.2
Informative..................................................................................................................................... 3
2
AIRM MODELLING ENVIRONMENT....................................................................................................... 4
3
THE UNIFIED MODELLING LANGUAGE (UML) .................................................................................. 5
3.1
3.2
4
ORGANISING THE AIRM .......................................................................................................................... 6
4.1
4.2
5
W HAT IS UNIFIED MODELLING LANGUAGE (UML)?............................................................................... 5
MODELS V DIAGRAMS............................................................................................................................. 5
PACKAGES .............................................................................................................................................. 6
DEPENDENCY ......................................................................................................................................... 6
CLASS DIAGRAMS: THE ESSENTIALS ............................................................................................... 7
5.1
CLASS ..................................................................................................................................................... 7
5.2
PROPERTIES ........................................................................................................................................... 7
5.2.1
Attributes ....................................................................................................................................... 8
5.2.2
Associations .................................................................................................................................. 8
5.2.3
Deciding how to model properties ............................................................................................. 8
5.3
MULTIPLICITY .......................................................................................................................................... 8
5.4
GENERALIZATION .................................................................................................................................... 9
5.5
NOTES AND COMMENTS ....................................................................................................................... 10
6
CLASS DIAGRAMS: ADVANCED CONCEPTS .................................................................................. 11
6.1
6.2
6.3
6.4
6.5
7
AGGREGATION AND COMPOSITION ...................................................................................................... 11
ASSOCIATION CLASSES ........................................................................................................................ 11
ABSTRACT CLASSES............................................................................................................................. 11
ENUMERATED TYPES............................................................................................................................ 12
STEREOTYPES ...................................................................................................................................... 12
REFERENCES ........................................................................................................................................... 13
12-Feb-2016 04:39 00.00.01
1 of 13
Project ID 08.01.03.
AIRM Guide For Managers
List of tables
Error! No table of figures entries found.
List of figures
Figure 1 - UML Package Diagram .......................................................................................................... 6
Figure 2 - UML Class Diagram ............................................................................................................... 7
Figure 3 - UML Class and Attributes ....................................................................................................... 7
Figure 4 - UML Association ..................................................................................................................... 8
Figure 5 - Multiplicity ............................................................................................................................... 9
Figure 6 - UML Generalization .............................................................................................................. 10
Figure 7 - Notes .................................................................................................................................... 10
Figure 8 - UML Composition ................................................................................................................. 11
Figure 9 - Abstract Class....................................................................................................................... 12
Figure 10 - Enumerated Type ............................................................................................................... 12
12-Feb-2016 04:39 00.00.01
2 of 13
AIRM Guide For Managers
Project ID 08.01.03.
1 Introduction
1.1 Scope and application
This guide provides overview information and practical guidance for managers and readers of the
AIRM Models. The guide is intended to be informative and is focused on supporting the
understanding of information models in a way that does not require deep (technical) modelling
knowledge and skills.
1.2 Intended readership
The target audience is:
 Operational Work Packages
 Airspace Users
 Non-modellers who have an interest in reading the AIRM
1.3 Acronyms and terminology
Term
Definition
AIRM
ATM Information Reference Model
ATM
Air Traffic Management
NAF
NATO Architecture Framework
UML
Unified Modelling Language
1.4 Adoption
This section describes external documents and other artefacts that, through reference in this text,
provide provisions that are considered as normative of this document. For dated references,
subsequent amendments to, or revisions of, any of these publications do not apply. For each
publication a description how it has been adopted/used in this set of documents is also provided.
Note: If a reference is expressed with a date then only that version, of the reference, is valid since it is
not possible to guarantee that newer versions, of referenced document, does not adversely impact
this document.
1.4.1 Normative
The following publications, documents and artefacts are considered as normative:

OMG Unified Modelling Language (UML), v2.1
1.4.2 Informative
There are no informative references.
12-Feb-2016 04:39 00.00.01
3 of 13
Project ID 08.01.03.
AIRM Guide For Managers
2 AIRM Modelling Environment
The following documents should be read before reading this Guide:

AIRM Primer. This sets the scene for the AIRM and introduces the AIRM Models.
12-Feb-2016 04:39 00.00.01
4 of 13
Project ID 08.01.03.
AIRM Guide For Managers
3 The Unified Modelling Language (UML)
The AIRM models are represented using the Unified Modelling Language (UML).
3.1 What is Unified Modelling Language (UML)?
The OMG specification [5] gives the following definition:
"The Unified Modelling Language (UML) is a graphical language for visualizing,
specifying, constructing, and documenting the artifacts of a software-intensive system.
The UML offers a standard way to write a system's blueprints, including conceptual
things such as business processes and system functions as well as concrete things such
as programming language statements, database schemas, and reusable software
components."
The intention behind the language is to encapsulate best practices in software design into a standard
yet extensible notation. The UML provides a number of standard diagramming notations, such as
uses cases, class diagrams, sequence diagrams, and activity diagrams. In addition, the UML has a
number of mechanisms, such as stereotyping, which allow modellers to tailor or extend the language
to suite their circumstances [1].
However, UML is not only for programmers [2]. UML is becoming the preferred language for
describing business systems.
3.2 Models v Diagrams
You will see that two terms have been used: “models” and “diagramming notations”. The terms have a
subtle difference:


A model is a collection of model elements representing a view at some level of abstraction
A diagram of that model is a way of representing the model graphically
However, in practices the terms model and diagram are often used interchangeably.
12-Feb-2016 04:39 00.00.01
5 of 13
AIRM Guide For Managers
Project ID 08.01.03.
4 Organising the AIRM
The AIRM is organised using UML packages. The packages are illustrated using package diagrams.
4.1 Packages
A UML package is a collection of model elements.
In AIRM, packages are used to group the entities into a given component or Subject Field. They are
used as a way of dividing the model into logical parts.
A package is shown on a diagram as a rectangle with a ‘tab’ on its top edge. The tab gives the name
of the package.
InformationModel
FoundationLibrary
«trace»
ConsolidatedLogicalDataModel
Figure 1 - UML Package Diagram
The elements contained by a package can be drawn inside the package symbol but need not be.
They usually aren’t (as above), since the amount of detail required to show all the contents of a
package usually makes this inconvenient: Indeed the main purpose of using a package is normally to
be able to hide this detail.
Packages can contain any model elements that you wish to group together. It can contain another
package. The hierarchical view of the model that results can be useful in large models. In the AIRM,
for example, the Information Model package contains other packages used to group the elements of
each SubjectField together.
4.2 Dependency
The dashed lines in Figure 1 show that the content of one package depends on the content of
another. In the AIRM it means that a change in the Foundation Library may alter the elements in the
Information Model or the Consolidated Logical Data Model.
12-Feb-2016 04:39 00.00.01
6 of 13
AIRM Guide For Managers
Project ID 08.01.03.
5 Class Diagrams: The Essentials
Class diagrams are used to illustrate the AIRM. Indeed, they are the most frequently used type of
UML diagram.
If someone were to come up to you in a dark alley and say, “Psst, wanna see a UML diagram?” that
diagram would probably be a class diagram. [4]
Figure 2 gives an example class diagram.
Aircraft
+
+
+
stallSpeed: Real
mass: Real
type: CodeAircraftType
+manufactures
AircraftManufacturer
+manufacturer
0..1
+
name: CharacterString
+operates
+engine
AircraftEngine
+operator
CodeAircraftType
+
+
AircraftOperator
{abstract}
+wing
Boeing747
AirbusA380
0..2
AircraftWing
CommercialAirline
MilitaryOrganisation
AirAmbulanceServ ice
Figure 2 - UML Class Diagram
5.1 Class
A UML class is the abstraction of a concept in the application domain. In the AIRM these should
derive from the information exchange requirements that are needed to support ATM operations.
A class is shown in a class diagram as a rectangle giving its name e.g. Aircraft.
Aircraft
+
+
+
stallSpeed: Real
mass: Real
type: CodeAircraftType
Figure 3 - UML Class and Attributes
5.2 Properties
Properties represent structural features of a class. Properties are a single concept but they appear in
two quite distinct notations:


Attributes
Associations
Although they look quite different on a diagram, they are really the same thing.
12-Feb-2016 04:39 00.00.01
7 of 13
AIRM Guide For Managers
Project ID 08.01.03.
5.2.1 Attributes
Attributes are represented as a line of text in the second compartment of the class symbol. In the
example, the Aircraft class has the following attributes:



stallSpeed
mass
type
You can now say that an Aircraft:
 has a stallSpeed
 has mass and
 has a type.
As shown Figure 3, each attribute may define its type (for example, CharacterString, Real or
DateTime). Many of these types will be found in the FoundationLibrary package (hence the
dependency mentioned in section 4.2).
5.2.2 Associations
Associations express the relationship between classes. UML represents an association between two
classes by drawing a line between their symbols.
Aircraft
+
+
+
stallSpeed: Real
mass: Real
type: CodeAircraftType
+manufactures
AircraftManufacturer
+manufacturer
0..1
+
name: CharacterString
Figure 4 - UML Association
The associations in the example have their navigability undefined. It is not stated in which direction
the relationship should be read. Indeed, associations generally can be read in two directions where
the role on the association end describes how the related class is used. This makes sense in some
cases.
In the example you can say:


The Aircraft has a property ‘manufacturer’. This is the role of AircraftManufacturer in the
association.
You can also say that an AircraftManufacturer ‘manufactures’ Aircraft.
It is sometimes necessary to have unidirectional navigability. This is shown by adding an arrow at
the destination end of the association. This means that the association is easily navigated in the
direction indicated by the arrow. This does not mean that the associations cannot be navigated in the
other direction but the directionality is a hint that implementations should make the navigation in the
primary direction convenient and efficient. One class knows about the existence of the other in the
direction of navigation but the reverse is not necessarily true.
In the case of unidirectional associations it is usual to specify a role for only the destination end
leaving the origin role anonymous.
5.2.3 Deciding how to model properties
In general I tend to use attributes for small things such as dates and Booleans – in general, value
types – and associations for more significant classes such as ‘customers’ and ‘orders’. [4]
5.3 Multiplicity
The multiplicity of a property is an indication of how many values are allowed for that property.
12-Feb-2016 04:39 00.00.01
8 of 13
AIRM Guide For Managers
Project ID 08.01.03.
Each attribute has an optional multiplicity specification that takes the form [m..n], where m is the
minimum number of values allowed for an attribute, and n is the maximum number of values. A
multiplicity of * represents zero or more, and a multiplicity of [1..1] may be specified using the
shorthand value of [1]. Multiplicity of [0..1] means that the attribute is optional i.e. it can appear once
or not at all.
An association end also specifies the multiplicity of the destination class. This is the same as for
attributes but the multiplicity expression is not enclosed by [ ]. In an association, multiplicities can be
given at both ends. This is one of the advantages of using an association rather than an attribute.
In UML, an attribute or association with no multiplicity specification defaults to [1..1]. That means it
must have exactly one value. However, the AIRM deviates from this convention as stated in AIRM
Foundation rules 22 and 26.
Rule 22
Attributes shall, by default, be represented with multiplicity of [0..1] (zero to one). If an operational
constraint has been identified then multiplicities should be chosen to reflect such
constraints.
Rule 26
Relationships shall, by default, be represented with multiplicity [0..*] (zero to many). If an
operational constraint has been identified then multiplicities should be chosen to reflect
such constraints.
Note: Further constraints may be added at “lower” levels of modelling such as in Physical Data
Models.
In order to save cluttering the diagrams, these defaults need not be represented.
Aircraft
+
+
+
stallSpeed: Real
mass: Real
type: CodeAircraftType
+manufactures
AircraftManufacturer
+manufacturer
0..1
+
name: CharacterString
Figure 5 - Multiplicity
In this example:
 The ‘stallSpeed’, ‘mass’, ‘type’ and ‘name’ attributes attribute are all optional [0..1].
 The AircraftManufacturer manufactures [0..*] Aircraft i.e. zero or more aircraft.
 The AIRM default is specifically overwritten for the Aircraft manufacturer property. An Aircraft
has a maximum of one manufacturer.
5.4 Generalization
The example model includes a generalization relationship. A generalization relationship is shown by
line with an open triangle at the super-class end.
The relationship can be described as a subclass being a type-of the super-class e.g. a
CommercialAirline is a type-of AircraftOperator.
12-Feb-2016 04:39 00.00.01
9 of 13
AIRM Guide For Managers
Project ID 08.01.03.
AircraftOperator
{abstract}
CommercialAirline
MilitaryOrganisation
AirAmbulanceServ ice
Figure 6 - UML Generalization
Generalization relationships are also referred to as inheritance. The relationship is composed of
super-classes and subclasses. The subclasses inherit their properties (attributes and associations)
from their super-classes. A subclass may then specify additional attributes and associations that are
not applicable to the super-class – this is referred to as specialisation.
5.5 Notes and Comments
Notes are comments in the diagrams. Notes can be stand-alone or they can be linked with a dashed
line to the elements they are commenting.
Any machine that can
derive support in the
atmosphere from the
reactions of the air
other than the
reactions of the air
against the earth’s
surface.
Aircraft
+
+
+
stallSpeed: Real
mass: Real
type: CodeAircraftType
Figure 7 - Notes
12-Feb-2016 04:39 00.00.01
10 of 13
AIRM Guide For Managers
Project ID 08.01.03.
6 Class Diagrams: Advanced Concepts
6.1 Aggregation and Composition
The example UML model makes uses of composition.
Aggregation and composition are both ways of recording that an object of one class is part-of an
object of another class. Composition means that the whole strongly owns its parts: if the whole object
is copied or deleted, its parts are copied or deleted.
Aggregation is represented by line with an open diamond at the “whole” end. Composition is
represented by a line with a closed diamond at the “whole” end.
Aircraft
+
+
+
stallSpeed: Real
mass: Real
type: CodeAircraftType
+engine
AircraftEngine
+wing
0..2
AircraftWing
Figure 8 - UML Composition
The association from Aircraft to AircraftWing is a composition type. This means that the lifetime of the
associated objects is dependent on the life of the container (for example, the life of AircraftWing is tied
to the life of its container Aircraft).
You can read this in two ways:


Aircraft is composed of zero or two AircraftWing, or
AircraftWing is part-of Aircraft.
By comparison, the association from Aircraft to AircraftManufacturer is not a composition so the same
part-of relationship does not exist. Deleting an Aircraft does not mean deleting the
AircraftManufacturer!
6.2 Association Classes
Sometimes the way in which two objects are associated is just as important as the objects
themselves. This amounts to treating the association between the two classes as a class in its own
right. This is called an association class.
6.3 Abstract Classes
An abstract class is a class that cannot be directly instantiated. Instead, you need to instantiate one
of its subclasses. An abstract class is shown using the {abstract} label and has its name italicized.
12-Feb-2016 04:39 00.00.01
11 of 13
AIRM Guide For Managers
Project ID 08.01.03.
For example, AircraftOperator is abstract and will not be instantiated. Instead, you will need to
instantiate CommercialAirline or MilitaryOrganisation or AirAmbulanceService.
AircraftOperator
{abstract}
MilitaryOrganisation
CommercialAirline
AirAmbulanceServ ice
Figure 9 - Abstract Class
6.4 Enumerated Types
The example model includes a class named CodeAircraftType. The naming convention of
‘Code…Type’ is used to show that the class is a codelist or enumerated type.
CodeAircraftType
Aircraft
+
+
+
stallSpeed: Real
mass: Real
type: CodeAircraftType
+
+
Boeing747
AirbusA380
Figure 10 - Enumerated Type
Enumerated types are part of many programming languages and are also useful when constructing
a conceptual model of an application domain. They can be used to limit the selection of attribute
values to one of a predetermined list. By convention in UML, attributes are added to the enumeration
class as a means to define the list of possible value tokens. No attribute types are necessary for these
enumerated list values.
Therefore, in this example, an Aircraft’s type attribute can only be either “Boeing747” or “AirbusA380”.
6.5 Stereotypes
Stereotypes are used to extend the core UML metamodel with additional modelling constructs to
visualise those extensions in a diagram. A set of related stereotypes might be grouped into a standard
profile that is used to model a specialised application domain. Or, as in the case of <<enumeration>>
a set of common stereotypes is defined as part of the UML specification.
12-Feb-2016 04:39 00.00.01
12 of 13
AIRM Guide For Managers
Project ID 08.01.03.
7 References
Title
1
2
3
4
5
Location
Software Systems Architecture, Nick
Rozanski, Eoin Woods
Modelling XML Applications with UML,
David Carlson
AIRM Primer
Addison Wesley
UML Distilled, Martin Fowler
Addison Wesley
OMG Unified Modelling Language
(UML), v2.1
http://www.omg.org/spec/UML/
Addison Wesley
SJU extranet: Project 08.01.03 > Project Execution
12-Feb-2016 04:39 00.00.01
13 of 13