Design of the Airport Application#
In this chapter, we explore the design of an airport application that
uses the time
, angle
, and say
libraries.
Goals of the airport application#
Throughout this book, we have been developing components for an airport application. This application deals with airports, aircraft, gates, and related objects. Objects in a simple airport. shows a diagram of a simple airport.
![../_images/figure-15-1.png](../_images/figure-15-1.png)
Objects in a simple airport.#
![../_images/figure-15-2.png](../_images/figure-15-2.png)
Transitions between sky and gate for outbound and inbound aircraft.#
In Objects in a simple airport., we see a single terminal, A. It has two gates, A1 and A2, a taxiway, Echo, a runway, 11R-29L, and an aircraft approaching the runway.
When landing, an aircraft goes from the sky to a runway to a taxiway to a gate. Transitions between sky and gate for outbound and inbound aircraft. is a state diagram showing these transitions for both inbound and outbound aircraft.
Our first goal for this application is as follows: given a set of incoming aircraft at various positions in the sky, we want to predict which gate each aircraft will use when it arrives, and to estimate the arrival time of the aircraft at the gate. This information is displayed on the Arrivals monitors in an airport.
Our second goal for the application is to provide additional information for the ground crew. We must state the entire path that an incoming aircraft will take, including the runway, the taxiway, and the gate. We must also state the time that an aircraft is expected to be at each point. For example, for an inbound aircraft, we want to display information like the following:
12:30: Aircraft Cardinal at Runway 11R-29L
12:43: Aircraft Cardinal at Taxiway Echo
12:47: Aircraft Cardinal at Gate A2
The application considers departing aircraft as well as arriving aircraft.
Objects that model an airport#
We need to define classes that represent the objects in Figures Objects in a simple airport. and Transitions between sky and gate for outbound and inbound aircraft. Note that the application displays information about the path of an aircraft from gate to sky and sky to gate; the aircraft stops at the gate and does not enter the terminal itself. Therefore, we do not need to define a terminal class. Our design includes these airport classes:
<airport>
,<gate>
,<taxiway>
,<runway>
,<sky>
,<vehicle>
,<aircraft>
A vehicle is any object that is self-propelled. Aircraft are vehicles that are capable of flying. In our design, the sky around the airport, the gates, the taxiways, and the runways each keep track of each aircraft as the latter moves from the sky to the gate and back to the sky again. One common attribute of the sky, gates, taxiways, and runways is that each of them can hold an aircraft, or more than one aircraft. Because these objects can hold vehicles, we can think of them as containers. Our design uses this class to represent all types of containers:
<vehicle-storage>
In our design, containers are connected to other containers. In the
airport diagram in Objects in a simple airport., gate A1 is
connected to taxiway Echo, which is connected to runway 11R-29L.
We can use a slot in the <vehicle-storage>
class to model these
connections.
Since some containers can hold only one aircraft, whereas other
containers have more complex behavior, our design includes two
subclasses of <vehicle-storage>
:
<single-storage>
,<multiple-storage>
Instances of <single-storage>
may hold a single aircraft regardless of
the direction of travel. Instances of <multiple-storage>
may hold more
than one aircraft, and each direction is treated separately. For
example, <gate>
is a subclass of <single-storage>
, and <sky>
is a
subclass of <multiple-storage>
.
All subclasses of <vehicle-storage>
must comply with the
vehicle-storage protocol. In particular, designers of
<vehicle-storage>
subclasses must ensure that the subclasses either
inherit or define methods for all the key vehicle-storage generic
functions.
Certain classes — such as the time and position classes — represent intangible concepts. Other classes — such as airports, gates, runways, and aircraft — represent physical objects. It may be useful to make that distinction in our classes, so we define a class from which all physical objects inherit:
<physical-object>
![../_images/figure-15-3.png](../_images/figure-15-3.png)
Inheritance relationships among classes that represent physical objects.#
Figure Inheritance relationships among classes that represent physical objects. shows the inheritance relationships among the classes that represent physical objects.
Behaviors of the objects#
The top-level function of our application is called process-aircraft
.
Given an airport that has been properly initialized, process-aircraft
will simulate and document the movement of all inbound aircraft through
all the containers of the airport, from landing through takeoff.
To predict how long it will take for an aircraft to arrive at the
airport, we need to compute the distance between the position of the
aircraft and the position of the airport. Then, we must divide the
distance by the speed to determine how long it will take the aircraft to
get from one position to the other. The flying-time
method will
implement that computation in our design.
Once an aircraft approaches the airport, it enters a series of containers. The generic functions that constitute the vehicle-storage protocol help us to generate and simulate the transitions of the aircraft from container to container.
We summarize some of the operations in our design here; we summarize the vehicle-storage protocol in The vehicle-container protocol.
process-aircraft airport time#
Generic Function#
This generic function simulates and documents the movement of aircraft through the airport, including the time of each transition — for example,
12:30: Aircraft Cardinal at Runway 11R-29L 12:43: Aircraft Cardinal at Taxiway Echo 12:47: Aircraft Cardinal at Gate A2
The airport is an instance of
<airport>
. Thetime
is an instance of<time-of-day>
.
distance-3d aircraft airport#
Generic Function#
This generic function returns the distance between its two arguments. The aircraft is an instance of
<aircraft>
, and the airport is an instance of<airport>
.
flying-time aircraft airport#
Generic Function#
This generic function returns the time that it would take for the aircraft to fly to the airport.
The vehicle-container protocol#
Once the aircraft approaches the airport, it enters a set of connected
containers on its way inbound to a particular gate. The aircraft
eventually turns around and heads outbound toward the sky. The
vehicle-container protocol manages the transition of aircraft from one
container to another. The generic functions that make up this protocol
are summarized next. For all the generic functions that follow, the
value of the vehicle parameter must be an instance of <vehicle>
,
the value of the container parameter must be an instance of
<vehicle-storage>
, and the value of the direction parameter must be
either the symbol #"inbound"
or #"outbound"
.
available? vehicle container direction#
Generic Function#
This generic function returns true if there is space in container for vehicle to enter for traveling in direction.
move-in-vehicle vehicle container direction#
Generic Function#
This generic function moves the vehicle into the container in the direction given.
move-out-vehicle vehicle container direction#
Generic Function#
This generic function moves the vehicle out of the container in the direction given.
next-out container direction#
Generic Function#
This generic function determines what vehicle, if any, could move to the next container. If there is such a vehicle, then next-out returns the vehicle, the next container in the direction of travel, and the time it would take to make that transition.
next-landing-step container vehicle#
Generic Function#
This generic function returns two values. The first value is the class of the next container into which vehicle may move from container. The second value is how long it will take vehicle to move into the next container. This generic function is used by the next-out generic function to accomplish part of the latter’s work.
Sorted sequences#
Part of what process-aircraft
will do in our example is to generate a
collection of possible transition steps for aircraft in or around the
airport. For example, if an aircraft is on the runway, then one possible
transition step would be to move the aircraft to the taxiway. If there
are many aircraft in the airport, there are many possible transitions
that might take place at various time. The process-aircraft
method
needs to consider these transitions in order. That is, if an aircraft is
ready to land on a runway in 5 minutes, but another one is ready to take
off in 2 minutes, process-aircraft
should attempt to complete the
take-off transition before completing the landing transition. To keep
these transitions in time order, we use a collection called a sorted
sequence.
Dylan does not provide a sorted sequence class in its built-in
collection library. However, Dylan does provide an extensible collection
framework that permits us to define sorted sequences ourselves. In fact,
Dylan already provides all the generic functions that we need to
interact with sorted sequences: size
, shallow-copy
, element
,
add!
, pop
, remove!
, and forward-iteration-protocol
.
We just need to provide methods for each of these generic
functions that implement these operations for sorted sequences. By
defining a method for forward-iteration-protocol
, we allow sorted
sequences to work with the standard Dylan collection iterators discussed
in Collections and Control Flow. Because sorted sequences are generally useful, we
define them in their own library, in the same manner as we did the time
and angle components.
Testing#
We include in the application a test library, which creates instances of
the classes described in this chapter, initializes these instances to a
reasonable state, and calls process-aircraft
. Providing test cases
(in a separate library) is a good way to check the design, interface,
and implementation of an application library.
Summary#
In this chapter, we covered the following:
We discussed the goals of the airport application: to predict the arrival time and gate of an incoming aircraft, and to describe the entire path that an incoming aircraft will take, including the time it is expected to be at each point.
We discussed the design of the airport application classes, and the operations to be performed on instances of the classes, including the vehicle- container protocol.
We discussed how the time, angle, sorted sequence, and testing libraries interact with the main airport application library.
In Definition of a New Collection, we implement sorted sequences. In The Airport Application, we implement the airport application.