You are on page 1of 31

Air Traffic Control

A Design Model in UML

Design Team:
Manisha Gupta (02261A1204)
Abhinav Murari (02261A1207)
Adibhatla Varun (02261A1218)
B. Rakesh Kumar (02261A1219)
1. Introduction 3

2. Problem Definition 4

3. Approach to the Solution 8

4. Class Diagram 11
4.1. Explanatory Notes 11
4.2. Diagram 13

5. Use Case Diagram 14

5.1. Explanatory Notes 14
5.2. Diagram 16

6. Sequence Diagrams 17
6.1. Explanatory Notes 17
6.2. Diagrams 19

7. Collaboration Diagrams 20
7.1. Explanatory Notes 20
7.2. Diagrams 21

8. State Chart Diagram 22

8.1. Explanatory Notes 22
8.2. Diagram 23

9. Activity Diagrams 24
9.1. Explanatory Notes 24
9.2. Diagrams 26

10. References / Bibliography 29

11. Appendix 30
11.1. List of Diagrams 30

The Human being has evolved and developed new solutions for his ever growing
needs. One such need is Transportation. Transportation, by definition is a means of
commuting from one place to another. Earlier, when the world was only existent only in
civilizations spread across the globe, each having no clue of the others existence, man
developed the wheel, so he could easily reach a destination within his region. Then, when
these civilizations expanded, they started trading, continents were discovered. This was
possible because man developed the ship, which could sail in the high seas and get man
even across water.

Now in the modern day world, we have developed automated means of

transportation. One of the most beneficial developments was the Aircraft. The Aircraft
could soar through the skies and get man anywhere he wanted in a matter of hours.
Though expensive, man preferred this mode of transportation to others, due to its speed
of service and efficiency. As time moved by, the skies began to get crowded with
aircrafts. A system was needed to control the traffic in the air, to prevent two aircraft
from traversing the same path and collide.

This System is known as the Air Traffic Control. It is a mechanism by which all
planes within its airspace are monitored and given instructions, regarding path, position,
speed etc. Every airport is equipped with an Air Traffic Control (ATC). These ATC are
responsible for the plane to take-off, accomplish the journey and land safely at the
destination airport.

The ATC consist of a large staff constantly monitoring the aircrafts in their
airspace. They do this with the help of sophisticated equipment, such as Radar Trackers,
Sensitive Weather Equipment etc. Such equipment needs software, which understands the
operations and tasks of the ATC. Some of the common software used at Airports are –
Traffic Management Advisor (developed by NASA) and FAST (also developed by

Today, before coding the software, we generate a model. A Model is basically a

design, similar to designing the blueprints for a house, before actually setting up steel
frames, bricks and concrete. We use the Unified Modeling Language (UML), developed
by Grady Booch, James Rambaugh and Ivar Jacobson. This modeling techniques
involves development of a set of descriptive Diagrams, namely, Class Diagrams, Use
Diagrams, Interaction Diagrams, Activity Diagrams and State Chart Diagrams in order to
generate a skeleton code, which is later expanded upon by the code developers.

We use this approach, in an attempt to design the model to facilitate the working
of an Air Traffic Controller.
Problem Definition

The Air Traffic Controller is the caretaker of the aircraft from the moment it is
undocked from the terminal at the source airport till it docks at a terminal at the
destination airport. The task of ensuring safe operations of aircraft falls on air traffic
controllers. They must coordinate the movements of thousands of aircraft, keep them at
safe distances from each other, direct them during takeoff and landing from airports,
direct them around bad weather and ensure that traffic flows smoothly with minimal
delays. The air traffic control system is much more complex than the image of men and
women in the tower of an airport that probably comes to mind.

The air traffic control system divisions are:

• Air Traffic Control System Command Center (ATCSCC) - The ATCSCC oversees
all air traffic control. It also manages air traffic control within centers where there
are problems (bad weather, traffic overloads, and inoperative runways).
• Air route traffic control centers (ARTCC) - There is one ARTCC for each center.
Each ARTCC manages traffic within all sectors of its center except for TRACON
airspace and local-airport airspace.
• Terminal radar approach control - TRACON handles departing and approaching
aircraft within its space.
• Air traffic control tower (ATCT) - An ATCT is located at every airport that has
regularly scheduled flights. Towers handle all takeoff, landing, and ground traffic.
• Flight service station (FSS) - The FSS provides information (weather, route,
terrain, flight plan) for private pilots flying into and out of small airports and rural
areas. It assists pilots in emergencies and coordinates search-and-rescue
operations for missing or overdue aircraft.

As an aircraft travels through a given airspace division, it is monitored by the one

or more air traffic controllers responsible for that division. The controllers monitor this
plane and give instructions to the pilot. As the plane leaves that airspace division and
enters another, the air traffic controller passes it off to the controllers responsible for the
new airspace division.

Flight Profile and Preflight

Every Flight follows a typical profile:
1. Preflight -This portion of the flight starts on the ground and includes flight
checks, push-back from the terminal and taxi to the runway.
2. Takeoff - The pilot powers up the aircraft and speeds down the runway.
3. Departure - The plane lifts off the ground and climbs to a cruising altitude.
4. En route - The aircraft travels through one or more center airspaces and nears the
destination airport.
5. Descent - The pilot descends and maneuvers the aircraft to the destination airport.
6. Approach - The pilot aligns the aircraft with the designated landing runway.
7. Landing - The aircraft lands on the designated runway, taxis to the destination
gate and parks at the terminal.

The pilot inspects the plane and files a flight plan with the tower -- all IFR pilots
must file a flight plan at least 30 minutes prior to pushing back from the terminal. The
pilot reviews the weather along the intended route, maps the route and files the plan. The
flight plan includes:
• Airline name and flight number
• Type of aircraft and equipment
• Intended airspeed and cruising altitude
• Route of flight (departure airport, centers that will be crossed and destination

The pilot transmits this data to the tower. In the tower, a controller called a Flight
Data Person reviews the weather and flight-plan information and enters the flight plan
into the host computer. The computer generates a Flight Progress Strip (FPS) that will be
passed from controller to controller throughout the flight. The flight progress strip
contains all of the necessary data for tracking the plane during its flight and is constantly

Once the flight plan has been approved, the flight data person gives clearance to
the pilot (clearance delivery) and passes the strip to the ground controller in the tower.

The ground controller is responsible for all ground traffic, which includes
aircraft taxiing from the terminal to takeoff runways and from landing runways to the
terminals. When the ground controller determines that it is safe, he or she directs the pilot
to push the plane back from the terminal (airline personnel operate the tugs that actually
push the aircraft back and direct the plane out of the gate area). As the plane taxis to the
runway, the ground controller watches all of the airport's taxiways and uses ground radar
to track all of the aircraft (especially useful in bad weather), ensuring that the plane does
not cross an active runway or interfere with ground vehicles. The ground controller talks
with the pilot by radio and gives him instructions, such as which way to taxi and which
runway to go to for takeoff. Once the plane reaches the designated takeoff runway, the
ground controller passes the strip to the local controller.

The local controller in the tower watches the skies above the airfield and uses
surface radar to track aircraft. He or she is responsible for maintaining safe distances
between planes as they take off. The local controller gives the pilot final clearance for
takeoff when it is deemed safe, and provides the new radio frequency for the departure
controller. Once clearance is given, the pilot must decide if it is safe to takeoff. If it is
safe, he accelerates the plane down the runway. As the plane leaves the ground, the local
controller hands the plane off electronically to the departure controller at the TRACON
facility that services the departure airport, but still monitors the plane until it is 5 miles
from the airport. The pilot now talks with the departure controller.

Once the plane takes off, the pilot activates a transponder device inside the
aircraft. The transponder detects incoming radar signals and broadcasts an amplified,
encoded radio signal in the direction of the detected radar wave. The transponder signal
provides the controller with the aircraft's flight number, altitude, airspeed and destination.
A blip representing the airplane appears on the controller's radar screen with this
information beside it. The controller can now follow the plane.

The departure controller is located in the TRACON facility, which may have
several airports within its airspace (50-mile/80-km radius). He or she uses radar to
monitor the aircraft and must maintain safe distances between ascending aircraft. The
departure controller gives instructions to the pilot (heading, speed, rate of ascent) to
follow regular ascent corridors through the TRACON airspace.

The departure controller monitors the flight during ascent to the en route portion.
When your plane leaves TRACON airspace, the departure controller passes the plane off
to the center controller (ARTCC controller). Every time the plane gets passed between
controllers, an updated flight progress slip gets printed and distributed to the new

En Route and Descent

Once the plane has left TRACON airspace, it enters a sector of the ARTCC
airspace, where it is monitored by at least two air traffic controllers. The radar associate
controller receives the flight-plan information anywhere from five to 30 minutes prior to
the plane entering that sector. The associate controller works with the radar controller in
charge of that sector. The radar controller is in charge of all air-to-ground
communication, maintains safe separation of aircraft within the sector and coordinates
activities with other sectors and/or centers. The controllers must monitor the airspace at
high altitude (above 24,000 ft/7320 m) and low altitude (below 24,000 ft). The center
controllers provide the pilot with updated weather and air-traffic information. They also
give directions to the pilot regarding such aspects as speed and altitude to maintain a safe
separation between aircraft within their sector. They monitor the plane until it leaves their
sector. Then they pass it off to another sector's controller.

In each sector, center controllers radio instructions to the pilots. The path of the
plane may have to be changed from the original flight plan to move around bad weather
or avoid a congested sector. The pilots may request a change in altitude to avoid or
reduce turbulence. This back and forth between pilots and center controllers continues
until the plane is about 150 miles (241 km) from the destination. At this point, the center
controller directs all planes flying into the destination to move from high altitudes to low
altitudes and merges the descending aircraft into a single file line toward the airport. The
controller gives instructions to the pilot, such as changes in heading, speed and altitude,
to place the plane in line with these other aircraft. Depending on traffic conditions, the
controller may have to place the plane into a holding pattern, which is a standard route
around each airport, where the plane waits until the airport can handle its arrival. The
controller continues to give directions to the pilot until the plane is within TRACON

When the descending plane is 50 miles from the destination airport, it is within
TRACON airspace. An approach controller directs the pilot to adjust the aircraft's
heading, speed and altitude to line up and prepare to land along standard approach
corridors. The pilot then aligns your plane with the runway. When the plane is 10 miles
(16 km) from the runway, the approach controller passes the plane off to the local
controller in the airport tower.

The local controller in the airport tower checks the runways and the skies above
the runways with binoculars and surface radar (local and ground controllers are the only
controllers licensed to use visual information in performing their duties). When the local
controller determines that it is safe, he or she gives the pilot clearance to land. The local
controller also updates weather conditions for the pilot and monitors the spacing between
the plane and other landing aircraft.

Once the plane lands, the local controller directs the plane to an exit taxiway.
Then tells the pilot the new radio frequency for the ground controller and passes the plane
off to the ground controller. The ground controller watches the runways and taxiways and
uses ground radar information to ensure that the taxiing aircraft does not cross active
runways or interfere with ground vehicles. He or she directs the plane to the appropriate
terminal gate. Ground personnel from the airline use hand signals to assist the pilot in
parking the airplane at the terminal.

Approach to the Solution

In order to generate the UML models for the above description, the identified
classes are as shown below:

The Classes
Plane Class:
This class represents the Aircraft. It has all the attributes of an aircraft, such as its
name, equipment, number, source, destination, air speed etc. The operations included are
to send the Flight Plan to the ATC and to receive the same. Another operation is to
request an altitude change. The responsibilities of this class will be to generate the flight
plan, take-off & landing, maintain stable flight etc.

Flight Plan Class:

The pilot uses this class to generate a Flight Plan. The attributes include all
necessary details for the generation of the flight plan. The operations include acquiring
weather conditions for the journey, selecting the route that the pilot intends to take and an
operation to send this information to the ATC. The responsibilities of this class are to
acquire the weather details and to select the route to reach the destination.

Flight Progress Strip (FPS) Class:

The Flight Data Person enters the flight plan into the computer and is given the
Flight Progress Strip. This class is created for this purpose. Its attributes cover all the
details of the FPS. The operations are to receive the flight plan, to generate FPS, issue
secondary clearance to the plane and to pass the FPS to the ground controller. Its
responsibilities are to create an FPS, issue Clearance and to transfer the FPS to the
ground controller.

ATC Class:
The ATC is the super-class for the FPS, ground and local controller classes. It is
responsible to receive the flight plan and forward it to the FPS class and to forward the
received FPS to the ground controller.

Local Controller Class:

The local controller checks the surface and skies for traffic and detects possible
collisions, it also issues the final clearance to the plane for takeoff and provides a
frequency to communicate with the departure controller. Similar operations are
performed by it during the landing procedure. The responsibilities are outlined as – check
sky & surface traffic, issue clearance, provide communication frequency and to invoke
ground controller while landing.

Ground Controller Class:

The ground controller releases the plane from the terminal and taxis it to the
runway assigned by it. The attributes used here are the runway and dock ID and the
towing vehicle availability. The responsibilities – docking / undocking, sense danger
while taxiing, assigning runway, invoking local controller while takeoff.

The TRACON Class is the super-class for the approach and departure controllers.
It has not attributes or operations.

Departure Controller Class:

The departure controller is responsible for the aircraft after is lifts off until it is 5
miles from the airport. Its responsibilities are to receive the transponder signal and track
the aircraft based on that and to pass on the FPS to the next ARTCC (Radio Controller).
The attribute used is an array of available frequencies.
Approach Controller Class:
The approach controller is responsible for the aircraft when the aircraft is 5 miles
form the airport until it touches down on the runway. Its responsibilities are to send the
parameters to which the pilot need to update, issue a hold incase of congested runways
and to pass on control to the local controller.

Flight Service Station (FSS) Class:

The pilot sometimes requires updates about the weather, routes and terrain, such
information is provided to him by the FSS via the controlling structure, that is, by Radio
Controller while enroute, and by the ATC while at the airport. Its responsibility is to
service the request of the pilot.

ARTCC Class:
This is the super-class of Radio Controller and Radio Associate Controller
classes. Its primary responsibility is to contact the next ARTCC in the path of the aircraft.

Radio Controller Class:

This is responsible for the aircraft during its flight. A plane crosses many radio
controllers as it accomplishes its flight, each controller has the id of the adjacent
controllers and are responsible for receiving the FPS, updating it and passing it on to the
next controller. Also if the pilot needs updates, then the radio controller must service his
request by sending him the updates of weather and air traffic, during landing it must also
invoke the approach controller.

Radio Associate Controller Class:

It executes the same function as the Radio Controller, useful in sectors where
congestion in the airspace exists. It has the same responsibilities as that of the radio
Class Diagram
Explanatory Notes:

A Class is description of a set of objects that share the same attributes, operations,
relationships and semantics. Graphically it is rendered as a rectangle. An Attribute is
named property of a class that describes a range of values that instances of the property
may hold. A class may have many attributes or no attributes at all. An attribute represents
some property of the thing you are modeling that is shared by the objects of the class.
They are shown in the compartment under the name of the class. An Operation is the
implementation of a service that can be requested from any object of the class to affect
behavior. They are written in the last compartment in the class depiction.

A Relationship is a connection among things. Graphically, it is rendered as a path,

with different kinds of lines to represent different kinds of relationships. A Dependency is
a relationship that a change in specification of one thing may affect another thing that
uses it, but not necessarily the reverse. It is represented as a dashed directed line. A
Generalization is a relationship between a general thing and a more specific kind of
thing. It is referred to as a “is-a-kind-of” relationship. It is represented as a solid straight
line with a large open arrowhead pointing to the parent. An Association is a structural
relationship that specifies that objects of thing are connected to objects of another.
Graphically, it is a solid line form one object to another. The adornment applied to this
line are – name, role, multiplicity and aggregation.

A Class Diagram is a diagram that shows a set of classes, interfaces,

collaborations and their relationships. Graphically, it is a collection of vertices and arcs.

The Air Traffic Model:

The classes identified for the Class Diagram of the Air Traffic Controller are
enlisted above. The relationships among each of these classes are as discussed below.

The Relationships:
The pilot of the plane generates a flight plan with the help of the Flight Plan class,
hence the relationship between the Plane class and Flight Plan class is a one-to-one
association named as generates and is uni-directed. The pilot then contacts the ATC and
sends his flight plan for processing, as there are many planes doing this at any point in
time the association is many-to-one, uni-directional and named as contacts. The air traffic
controller depends on the flight plan in order to generate a Flight Progress Strip, thus a
dependency is specified from the ATC class to the Flight Plan class. The ATC then
generates the Flight Progress Strip, which is single for each plane thus the one-to-one
association. The Local and Ground Controllers are sub-classes of the ATC class and are
hence specified by the generalization relationship. As discussed earlier, during take-off
the ground controller hands over control to the local controller and the reverse applies
while landing, thus each of them are interdependent on the other, which has been
specified by the dependency relationships.

Once the plane has lifted off the runway, the control of the plane is handed over to
the Departure Controller, which is a sub-department of the TRACON. Thus the
relationship between the ATC and the TRACON is a bidirectional one-to-one
association; the dual direction is because during the landing procedure, the Approach
Controller (also a sub-department of the TRACON) hands over the plane to the Local
Controller (sub-department of ATC). As mentioned above, the departure controller and
approach controller are sub-departments of TRACON and hence the relationship
specified is a generalization.

When the plane is 5 mile from the airport airspace, the Departure Controller hands
over the plane to the next ARTCC, the relationship between the TRACON and ARTCC
classes is a one-to-one bidirectional association. The reverse direction is for the landing
procedure where the ARTCC hands the plane over to the Approach Controller. The
ARTCC is composed of two sub-departments, namely, Radio Controller and Radio
Associate Controller which is depicted by the generalization relationship. The Radio
Controller gains control of the plane from either the Departure Controller or the previous
ARTCC (Radio Controller), this is specified by a recursive one-to-one uni-directional
association named as - transfers control. In areas where air traffic is highly congested, it
is impossible for the Radio Controller to manage all the traffic, thus it summons the help
of the Radio Associate Controller; this is shown by the means of a dependency
relationship between the Radio Controller and the Radio Associate Controller.

At any point in time, the pilot of the aircraft may request for updates on the
weather and air-traffic in that area, such requests are serviced by the Flight Service
Station class, which keeps track of weather, air traffic, terrain, air-routes etc. The pilot
sends a request to his controller which in-turns invokes the FSS class, thus a dependency
is specified from all classes to the FSS Class.

Flight Plan ATC Flight Progress Strip

AirlineName Status CallSign
FlightID AircraftType&Eqiupment
AircraftType getFlightDetails() GroundSpeed
AircraftEquipment receiveFPS() StripAmendments
Airspeed Plane 1 PreviousFix
+contacts 1
Altitude 1 Altitude
+generates AirlineName +generates
RoutePlan RoutePlan
1 1 BeaconCode
sendToATC() AircraftNumber n
1 FlightID
selectRoute() Source
getWeatherDetails() Destination
Flight Service Station +contacts CoordinationFix
receiveData() Local Controller
WeatherConditions Remarks
requestAltitudeChange() Safe
Routes FrequenciesAvailable
Terrain getFlightDetails()
checkSkyTraffic() generateSecClearance()
receiveRequest() checkSurfaceTraffic()
serviceRequest() sendToGroundControl()
callGroundController() Ground Controller
+transfers control ARTCC +contacts TRACON
1 contactNextARTCC() 1 1 RunwayID
1 TowingVehicleAvailable

Radio Assciate Radio Controller Departure Controller Approach Controller senseDanger()

Controller selectRunway()
ControllerID FrequenciesAvailable
ControllerID assignRunway()
AdjControllers adjustParameters()
AdjControllers taxiAircraft()
issueHold() receiveTrSignal()
receiveStrip() callLocalController() senseDanger()
receiveStrip() undock()
transferStrip() radarTracking()
transferStrip() callLocalController()
locateNextATC() callRadioController()
locateNextATC() updateFPS()
updateFPS() sendWeatherUpdate()
sendWeatherUpdate() sendAirTrafficUpdate()
sendAirTrafficUpdate() serviceRequest()
serviceRequest() sendFlightParameters()
sendFlightParamters() requestAssociateRC()
contactRC() callApproachControl()
Use-Case Diagram
Explanatory Notes:

A Use-Case specifies the behavior of a system or a part of the system and is a
description of a set of sequences of actions, including variants, which a system performs
to yield an observable result of value to an actor. Use-cases provide a way for the
developers to come to a common understanding with the system's end users and domain
experts. Graphically, a use-case is rendered by an ellipse.

A Use-Case diagram is just a special kind of diagram and shares the same
common properties as do all other diagrams – a name and graphical contents that are a
projection into a model. In a use-case diagram, there is a system boundary and the actors
stay outside the boundary and the use-cases are kept inside the boundary.

Use-Case diagrams commonly contain

• Use cases
• Actors
• Dependency, generalization, and association relationships

The Air Traffic Model:

The Use-Case diagrams can be efficiently used to describe the operations of the
Air Traffic Controller by representing the actors and how they use the functions vested
in them.

The Actors and Use-Cases:

To understand the working of the Air Traffic Controller we take the help of use-
cases, here we consider certain actors and monitor their roles. The first actor is the Local
Controller, the roles of which are checking the sky and surface traffic, to provide a
communication frequency to the pilot, issuing clearance (an extension is generating
secondary clearance) and calling the ground controller, each of these roles are
represented as use-cases connected to the actor with an association relationship. The
second actor is the Ground Controller, whose role is to select the route for the aircraft,
taxi the aircraft to and from the runway, dock and undock the plane from the terminal,
selecting and assigning a runway and calling the local controller. The ground controller
contacts the local controller during landing and the reverse procedure is applicable while
take-off. The third actor is the Approach Controller whose role is to adjust the parameters
of the incoming aircraft, issue a hold if the runways aren’t free and to call the local
controller. The use case to call the local controller is common to both the ground
controller and the approach controller and is hence shared by the actor.
The fourth actor is the Departure Controller; his roles are to first receive the
transponder signal emitted by the plane and then track the aircraft on his radar screen. An
additional role is to contact the next Radio Controller who will take over control of the
airplane once it leaves the TRACON airspace. Another crucial role is to sense danger and
intimate the pilot. The fifth actor is the Pilot (Air Crew) of the plane accomplishing the
journey, his roles are to send and receive data (FPS), getting flight and weather details,
requesting an altitude change in case of certain events and to sense danger. These roles
are all depicted as use-cases in the diagram and linked with the actors through the
association relationships as shown. The sixth actor is the Air Traffic Controller, whose
primary role is to generate the Flight Progress Strip, which is passes on from centre to
centre during the flight, the other role is to acquire the flight plan from the plane and pass
it on to the FPS class. The ATC and the air crew contact each other and are hence
associated with each other.

The seventh actor is the ARTCC whose only role is to contact the next ARTCC in
the path of the plane. The eighth actor is the Radio Controller. The radio controller's roles
include sending flight parameters, servicing requests made by the pilot, sending updates
on air traffic and weather conditions, receiving the FPS, updating and transferring it to
the next ARTCC, locating the next ARTCC, sending information to ATC(includes
sending information to pilot), and calling the approach controller during the landing
procedure. The last actor is the Radio Associate Controller, whose roles are the same as
that of the Radio Controller, only its services are used when congestion exists in the
airspace, and an extra role is to contact the radio controller. The radio controller and the
radio associate controller are a part of the ARTCC, and hence the generalization
relationship. The radio controller and the radio associate controller contact each other and
are dependent on each other.

< < in c lud e > >

C h e c k S k y Tra ffic G e n e ra t e S e c C le a ran c e C o n ta c t R a d io C n t .
Tra n s fe r S trip
R e c e ive S t rip
< e x te n d > > S e n d In fo To P ilot
C h e c k S u rfa c e Tra<ffic
S e n d In fo To A TC

Is s u e C le a ra n c e L o c a te N e x t A TC
R a d io A s s o . C n t .
L o c a l C n t.
P ro vide F re q u e n c y
C a ll G ro u n d C n t . S e n d W e a th e r U p d a te

S e le c t R o u t e S e n d A ir Tra ffic U p d a te

Ta x i A irc ra ft S e rvic e R e q u e s t
U p d a te F P S R a d io C n t.
D o c k / U nD o c k

G ro u n d C n t.
S e n d F lig h t P a ra m e te rs
A s s ig n R u n w a y S e n d In fo To G ro u n d C n t.
S e n d F P S To G ro u n d C n t .
S e le c t R u n w a y
C a ll L o c a l C n t.
C a ll A p p ro a c h C n t.

Is s u e H o ld A R TC C .
S e n d D a t aG e t W e a t h e r D e ta ils C o n ta c t N e x t A R TC C

R a d a r Tra c k in g
A p p ro a c h C n tA. d ju s t P a ra m e te rs
R e c e ive Tra n s p o n d e r S ig n a l R e c e ive D a t a G e n e ra t e F P S
R e q u e s t A lt it ud e C h a n g e

S ens e Danger
C a ll R a d io C n t . G e t F lig h t D e ta ils

n + c o n ta c t s 1
D e p a rt u re C n t . P ilo t (A ir C rew ) A TC .
Sequence Diagrams
Explanatory Notes:

An Interaction is a behavior that comprises a set of messages exchanged among a
set of objects within a context to accomplish a purpose. We use interactions to model the
dynamic aspects of the model. When an object passes a message to another object, the
receiving object might in turn send a message to another object, which might send a
message to yet another object, and so on. This stream of messages forms a sequence. Any
sequence must have a beginning; the start of every sequence is rooted in some process or
thread. Each process or thread within a system defines a distinct flow of control, and
within each flow, messages are ordered in sequence by time. A Sequence Diagram is an
interaction diagram that emphasizes the time ordering of the messages. Graphically, a
sequence diagram is a table that shows objects arranged along the X-axis and messages,
ordered in increasing time, along Y-axis.

A Sequence Diagram has an Object Lifeline, which is a vertical dashed line that
represents the existence of an object over a period of time. Objects can be created and
destroyed during this life time. The second feature of a sequence diagram is the focus of
control, which is a tall, thin rectangle that shows the period of time during which an
object is performing an action, either directly or through a subordinate procedure.

The Air Traffic Model:

The Air Traffic Model involves two sequences, where the flow of control is
relevant. The first is the Take-off Sequence and the second is the Landing Sequence.

Take-Off Sequence:
The Take-off sequence involves preparing a flight plan, undocking from the
terminal, taxiing to the runway, taking off and establishing contact with the ATC, as
defined in the problem definition. The objects identified for the diagram are, P : Plane,
A : ATC, G : Ground Controller, L : Local Controller, D : Departure Control and R :
Radio Controller.

The Sequence starts when the pilot of the plane creates a flight plan, and passes it
on to the ATC, through the function sendToATC(). The ATC generates a Flight Progress
Strip (FPS) and sends it back to the plane and also to the Ground Controller. The Plane
now undocks and requests a Runway from the Ground Controller, which does so and
assigns a runway to the plane, this is done with the functions – undock() and
assignRunway(). The Local Controller is invoked by the ground controller and given the
plane frequency, meanwhile the plane taxis to the runway and contacts the local
controller, the local controller must check the surface and sky traffic and issue clearance
to the plane along with a frequency to communicate with the Departure Controller, the
functions involved are taxiAircraft(), issueClearance() and provideFrequency(). The
ground controller object is destroyed at this point.

Once the plane is on the runway, it prepares for take off and sends its transponder
signal to the departure control, this is done with the sendTransponderSignal(). The
departure Control tracks the plane with the function radarTracking(), meanwhile the
ATC and the local controller objects are destroyed. The plane then takes off and contacts
the Radio Controller with the function contactRC() and sends the FPS. The radio
controller then updates the FPS and keeps passing it to the adjacent radio controllers. The
function of the radio controllers is to update the FPS, send weather and air traffic updates
to the plane.

Landing Sequence:
The Landing sequence involves contacting the Approach Controller, aligning the
aircraft, landing, taxiing and docking at the terminal. The Objects defined are P : Plane, R
: Radio Controller, A : Approach Controller, L : Local Controller and G : Ground

While in-flight the plane is in constant contact with the Radio Controller, which
receives its FPS, updates it and returns it, also it is responsible for giving weather and air
traffic updates to the plane. As the plane approaches the destination airport, the plane
sends a request to land to the Approach Controller through the requestToLand() function,
the approach controller processes the request and assigns new parameters to the plane or
puts it on hold, this is done with adjustParameters() and issueHold(). The radio controller
object is destroyed. The pilot aligns his aircraft as per the given instructions and awaits
clearance from the local controller, which is invoked by the approach controller, telling it
that a plane needs to land and is awaiting clearance. The local controller checks the sky
and surface traffic and issues clearance as well as provides a frequency for the plane to
communicate with the ground controller, also the approach controller object is destroyed.

On receiving clearance, the plane requests the Ground Controller for a Runway,
the ground controller selects and assigns a runway to the plane with the assignRunway()
function. The local controller object is destroyed. The pilot now reduces power and lands
his aircraft on the runway, the ground controller assigns a towing vehicle to the plane,
which taxis it to the terminal, and the docking procedure is then carried out.
Take Off Sequence
P : Plane A : ATC G : Ground Controller L : Local Controller D : Departure Controller R : Radio Controller

1: Send Flight Plan

2: Sec Clearance 3: FPS to Ground Cnt.

4: Undock
5: Assign Runway 6: Call Local Cnt.

7: Taxi Aircraft
8: Issue Clearance and Provide Frequency

9: Send Transponder Signal

10: Track On Radar 11: Call Radio Cnt.

12: Contact Radio Controller

13: Updates

Landing Sequence
P : Plane R : Radio A : Approach L : Local G : Ground
Controller Controller Controller Controller

1: Send FPS

2: Transfer FPS

3: Request To Land
5: Call Local Cnt.
4: Adjust Parameters
6: Await Clearance
8: Call Ground Cnt.
7: Issue Clearance &
Provide Frequency
9: Request Runway
10: Assign Runway
11: Land Aircraft
12: Taxi & Dock Aircraft

Collaboration Diagrams
Explanatory Notes:

The Definition:
Collaboration is a society of classes, interfaces and other elements that work
together to provide some cooperative behavior that’s bigger than the sum of all its parts.
The structural aspect of collaboration includes any combination of classifiers, such as
classes, interfaces, components and nodes. That is, it specifies the classes, interfaces and
other elements that work together to carry out the named collaboration. Graphically, the
classifiers are arranged like in any other UML Diagram, and related using the common

A Collaboration Diagram is an interaction diagram that emphasizes on the

structural organization of the objects that send and receive messages. It shows a set of
objects, links amongst them and messages sent ad received by them.

The Air Traffic Model:

The Collaboration Diagrams are used to show the structural aspects of the Air
Traffic Model. The two diagrams used are the Take-Off & Landing Sequences.

Take-Off Sequence:
As can be seen in the diagram, the object of plane class, p, sends the flight plan to
the ATC, which generates an FPS and sends it back to the Plane along with secondary
clearance. It also sends the FPS to the ground controller, which now has control of the
plane. Next the plane undocks from the terminal and requests a runway, the ground
control services the request and assigns a runway to the plane. As the aircraft is taxied to
the runway, its control is given to the local controller, which issues the final clearance for
take off. Once of the ground, the plane is under the jurisdiction of the Departure
Controller, to which the plane sends its transponder signal, to be tracked on the radar
monitor. When the plane is 5 miles from the airport airspace, it is handed over to the next
ARTCC (Radio Controller) on its route, the function of the radio controller is to track and
update the pilot at all times, when the plane is in his airspace. The control is passed on
from ARTCC to ARTCC as the plane accomplishes its journey.

Landing Sequence:
As the plane crosses its last ARTCC before the destination airport, its FPS is
updated and sent to it, once within 5 miles, the pilot requests permission to land, to which
the approach controller replies with new parameters. The pilot aligns the aircraft and
waits for clearance from the local controller, once the clearance is issued; the pilot
requests a runway and is assigned one by the ground controller. The pilot then lands his
aircraft and taxis to the terminal.

Take-Off Sequence
1: Send Flight Plan 3: FPS to Ground Cnt.

4: Undock
2: Sec Clearance
P: G : Ground
Plane Controller
5: Assign Runway
12: Contact Radio Controller
13: Updates

7: Taxi Aircraft
9: Send Transponder Signal
R : Radio
8: Issue Clearance and 6: Call Local Cnt.
Provide Frequency 10: Track On Radar

11: Call Radio Cnt.

L : Local
Controller D : Departure

Landing Sequence

R : Radio
1: Send FPS Controller

2: Transfer FPS
3: Request To Land

4: Adjust Parameters
A : Approach
9: Request Runway Controller
11: Land Aircraft

6: Await Clearance
10: Assign Runway
12: Taxi & Dock Aircraft

7: Issue Clearance & 5: Call Local Cnt.

Provide Frequency

G : Ground
8: Call Ground Cnt. Controller

L : Local

State-Chart Diagram
Explanatory Notes:

The Definitions:
A State Machine is a behavior that specifies the sequence of states an object goes
through during its lifetime in response to events, together with its responses to those
events. A State is a condition or situation during the life of an object during which it
satisfies some condition, performs some activity, or waits for some event. An Event is the
specification of a significant occurrence that has a location in space and time, i.e. it can
trigger a state transition. A Transition is a relationship between two states indicating that
an object in the first state will perform certain actions and enter the second state when
specified event occurs and conditions are satisfied. An Activity is an ongoing non-atomic
execution within a state machine. An Action is an executable atomic computation that
results in the change of a state. Graphically, a state is a rectangle with rounded edges, and
a transition is solid directed line.

A State Chart Diagram shows a state machine, emphasizing the flow of control
from state to state. Graphically, it is a collection of vertices and arcs. We use the state-
chart diagram to model the dynamic aspects of the system.

The Air Traffic Model:

This State chart diagram shows the transitions of the plane’s state and the control
(also anomaly avoidance) rendered by the ATC and its various departments (TRACON &
ARTCC namely). There are some basic inclusions slightly different from the class
diagrams as some of the state changes are taken care by the Radio Controller and Radio
Associate Controller.

The States and the Transitions:

The first state is the preflight state, where the plane is diagnosed and the pilot
prepares the flight plan. In case of any errors, the plane is halted and a recheck is done,
then the pilot requests for a runway, a towing vehicle and is then taxied to the runway,
here he waits for take-off clearance, during this wait the last minute checks are
performed, if all is fine the plane takes off and is handed over to the Departure Controller,
otherwise it is taxied back and rechecked. Once in the air, the plane’s control is passed on
the next ARTCC on its route which passes it on to the next ARTCC enroute, thus the
recursive loop on this state, when the plane reaches its destination, it is handed over to the
Approach Controller (TRACON). Once cleared to land the ATC controls the plane and is
responsible for landing, taxiing and docking the aircraft.

One aspect where the ATC system is of great help is in the case of anomalies,
which can occur when the plane is at any stage of its flight. The recognized anomalies are
Avionic Failure, in which case the pilot searches for the nearest runway and lands, if no
runway is found then the pilot is forced to belly land. The next is bad weather or
possibility of a collision between two aircraft; in both cases the pilot is assigned new
altitudes. A change in speed or deviation of path is corrected with required alterations.
E r ro r s W a it W a it W a it

P r e f l i gD h i at g n o R s et i qc us eR s e t q u e s tT aT xo iw TiRno eg q . T a Pk e ro f ro o f fm T aL xa is At w a y
R u n w a Vy e h i c l eR u n w aC y l e a r a nM c i en u t e C h e c k s

R e q u eT sr at n s f e r TC r ao n st r foe l r tTCo r oa n ts r foe l r T t Cor a o n n s t fr eo r l C o n t ar oc Tl t at o k e - O f f

L a n d i n gD e s t . A dT Ce s t . T R T A o C N O e Nx t hA o R s Tt CT CR A A C T OC N

G iv e n F o u n d
S e a rc h n e a re s t
N o t G iRv eu nn wo ar y s A n o m a lie s
Low F uel
N ot F ound
T a x i B e ll y L a n d
A ric ra ft A v i o n i Bc sa d P o s s Ci b h l ea n g Pe a i nt h
F a i l u rWe e a t Ch eo rl l i s iS o pn e e Dd e v i a t i o n

D ock

C h a n g e R e s e tR e s e t
A l t i t u d e S p e e dH e a d i n g

T ra c e b a c k th e c o n tro l to a s
b e fo r e o c c u r e n c e o f a n o m a ly
Activity Diagram
Explanatory Notes:

The Definition:
Activity diagrams describe the workflow behavior of a system. Activity diagrams
are similar to state diagrams because activities are the state of doing something. The
diagrams describe the state of activities by showing the sequence of activities performed.
Activity diagrams can show activities that are conditional or parallel.

Activity diagrams should be used in conjunction with other modeling techniques

such as interaction diagrams and state diagrams. The main reason to use activity diagrams
is to model the workflow behind the system being designed. Activity Diagrams are also
useful for: analyzing a use case by describing what actions needs to take place and when
they should occur; describing a complicated sequential algorithm; and modeling
applications with parallel processes.

However, activity diagrams should not take the place of interaction diagrams and
state diagrams. Activity diagrams do not give detail about how objects behave or how
objects collaborate.

Activity diagrams show the flow of activities through the system. Diagrams are
read from top to bottom and have branches and forks to describe conditions and parallel
activities. A fork is used when multiple activities are occurring at the same time. The
branch describes what activities will take place based on a set of conditions. All branches
at some point are followed by a merge to indicate the end of the conditional behavior
started by that branch. After the merge all of the parallel activities must be combined by a
join before transitioning into the final activity state.

The Air-Traffic Model:

There are FIVE major operations that have been specified in these series of
Activity Diagrams. They are:
• Pre-Flight
• Taxiing
• Take-Off
• In-Flight
• Landing

These above mentioned operations are the fundamental responsibilities that the
Air-Traffic Controller has to oversee. Diagrams have been made in order to achieve the
Common Modeling Technique of the Activity Diagrams, which is to Model a Workflow.
Hence keeping a specified workflow in mind, the Activity Diagrams have been drawn.

Phase 1: Pre-Flight
The sequence of the Workflow is as follows:
• The ATC asks different modules of the Airport to report to it for a status report to
decide whether the Aircraft may depart or not
• The Different modules of the Airport are: The Ground Control, The Airport
Terminal, The Baggage Control and the Pilot.
• Ground Control takes care of Fuel, Preliminary Aircraft Check
• Airport Terminal’s function is to see to it whether all Passengers have boarded the
Aircraft or not.
• Baggage Control loads the Baggage into the Aircraft.
• The Pilot checks the status of his Avionics, the Crew and whether all Passengers
have boarded the Aircraft.
• The above operations from the Ground Control onwards are concurrent in nature.
If all of them have been completed a report is generated by each module and
submitted to the ATC.
• On failure to perform any one of the operations, the ATC has to reschedule the
flight, otherwise, on successful completion the Aircraft may Taxi to the runway.

Phase 2: Taxi
• The ATC assigns a specified runway to the Pilot
• The Ground Control and the Pilot acknowledge the assignment and perform their
(concurrent) duties:
• The Ground Control instructs a tug to tug the aircraft to the specified runway and
keep it in position.
• The Pilot taxis to the start of the Runway and awaits the Clearance Signal.

Phase 3: Take-Off
• The ATC gives the Clearance to the Pilot for Take-Off
• The Pilot acknowledges the signal and proceeds to Take-Off

Phase 4: In-Flight
• The ATC instructs the Pilot to go to a specified Heading and Altitude after Take-
• In the event of a possible collision with another Aircraft, the ATC changes course
of one of the aircraft to a more safer course heading and altitude
• In Case the ATC is Out-Of-Range of the departing aircraft, all control is shifted to
the next In-Range ATC.

Phase 5: Landing
• The ATC clears the Runway and assigns the specified runway to the Approaching
• The Pilot acknowledges this designation and sets his ILS (Instrument Landing
System) to the specified runway.
• On Landing, the ATC acknowledges the event and instructs the Pilot to Taxi to a
particular Terminal to Off-Load Cargo/Passengers.
• Pilot Taxis to the specified runway and Flight is Complete

ATC Ground Control Airport Baggage Pilot


Fuel Check Passenger All Bags Check

Check Loaded Avionics

Aircraft Check Generate Passenger Check

Report Generate Communications
Baggage Report

Generate Check Crew

Report Status

Generate Pilot


Ground Cnt. ATC. Pilot.


Tow Aircraft to Acknowledge Runway

Runway Assignment

Taxis and Waits

for Clearance


If any
Reschedule Abort

Proceed To



Instructs Pilot to go to the

specified Heading and Altitude

If No Collision Continue Current

Heading and Altitude

Change Course to Safer

Heading and Altitude

If Out of Range Move Control To Next

ATC In Range

ATC.. Pilot.. Baggage.. Airport Staff

Clears Runway and

Assigns Pilot the Runway

Acknowledge Landing
Clearance and Land

Instruct Pilot To
Taxi To Terminal

Await approaching Await approaching

aircraft at terminal aircraft at terminal.

Taxi to runway

References / Bibliography
Reference Books:
1. The Unified Modeling Language – User Guide, Grady Booch, James Rambaugh,
Ivar Jacobson, Pearson Education.
2. Object Oriented Analysis and Design, Grady Booch, Pearson Education Asia.

List of Diagrams:

1. Flight Profile Page 5 How Stuff Works ©

2. Transfer of Control Page 7 How Stuff Works ©
3. Class List Page 8
4. Class Diagram Page 13 Rational Rose ©
5. Use Case Diagram Page 16 Rational Rose ©
6. Sequence Diagram – Take off Page 19 Rational Rose ©
7. Sequence Diagram – Landing Page 19 Rational Rose ©
8. Collaboration Diagram – Take off Page 21 Rational Rose ©
9. Collaboration Diagram – Landing Page 21 Rational Rose ©
10. State Chart Diagram Page 23 Rational Rose ©
11. Activity Diagram – Preflight Page 26 Rational Rose ©
12. Activity Diagram – Taxi Page 26 Rational Rose ©
13. Activity Diagram – Take-off Page 27 Rational Rose ©
14. Activity Diagram – Inflight Page 27 Rational Rose ©
15. Activity Diagram – Land Page 28 Rational Rose ©