An Object Oriented Analysis Of Air Traffic Control

Celesta Ball
Rebecca Kim
WP 90W00542
August 1991
Approved for public release, distribution unlimited
MITRE Corporation, McLean, Virginia
Table of Contents

SECTION 2
METHODOLOGY

2.1 THE OBJECT-ORIENTED ANALYSIS TASK

Object-oriented analysis (OOA) identifies the data, control, and process of a domain, with that order of emphasis. (In contrast, the order of emphasis in functional decomposition is process - control - data, and in event-response analysis is control - process - data. Functional decomposition and event-response analysis are forms of structured analysis.) (Winblad, Edwards, and King, 1990). This paper is concerned with two special forms of OOA: domain analysis and problem analysis. Domain analysis is OOA which includes the classes and objects common to all systems within a given domain. Problem analysis is OOA restricted to the classes and objects of a particular problem or application system. [Throughout this paper, the acronym OOA is used only to represent object-oriented analysis as a methodology, and is not used to refer to a particular application of OOA.]

A task was devised to demonstrate that the objectives of the object-oriented analysis (stated in section 1.2) could be met. (An earlier task had shown that OOA was appropriate for use as an analysis tool in the present task, because object-oriented techniques [1] emphasize the integration of data and operations, rather than algorithms, as fundamental system building blocks and [2] embody an incremental, iterative software development process rather than the waterfall life cycle. The methodolody particular to Peter Coad [Coad and Yourdon, 1991] was studied; it was decided that his methodology, perhaps modified and expanded, contained the essential elements of OOA and could be used as a starting point.) The objectives themselves were selected with the goal of showing that an object-oriented model of air traffic control has a use consistent with the I-Lab goals of (1) providing a capability to perform integration studies among individual NAS subsystems, procedures, and airspace, and (2) defining new operational concepts that will lead to increased system safety and capacity. While legacy software in the form of simulations, prototypes, and operational prototypes is expected to play a large supporting role in I-Lab experimentation, such software cannot be expected to cover every experimental need, given that I-Lab experimentation, by definition, looks at the horizontal integration of NAS components and most legacy software has been derived for a vertical application. The objectives were selected to provide a way to assess the ability of legacy software to meet experimental needs, by defining a "common language" in which both could be described before carrying out a direct comparison. The objectives also support the ability to define new software in this common language. The basic steps of the methodology used to meet the objectives are as follows:

  1. Create a model of ATC as a reference model, i.e., derive the "common language."

  2. Define the experiment of interest in the common language, i.e., create an experiment model.

  3. Define the available legacy software in the common language, i.e., create legacy software models.

  4. Directly compare the experiment model with the legacy software models, thus assessing the ability of the legacy software to meet experiment needs.

    In the following description of the task, the term "model" is used to refer to a collection of information about a domain, including its structures, views, and specifications (see figure 2-1). Each of these concepts is described further below in section 2.2; specifically, structures are described in section 2.2.3, views in section 2.2.5, and specifications in section 2.2.6.

    Figure 2-1. A Model

    The task was carried out in two subtasks, as illustrated by figure 2-2: a domain analysis of the ATC system followed by a problem analysis for a possible experiment. The domain analysis subtask resulted in an ATC model, which is described in more detail in section 3 and appendix A. The problem analysis subtask resulted in an experiment model and two legacy software models, based upon the ATC model and upon the written and verbal knowledge of the experiment and software authors. (Although there are more than two pieces of legacy software, it was decided that analysis of only two legacy software models was needed to demonstrate the methodology.) The process of using the ATC model as a reference model in creating new models, shown in the figure as information "passing through" the ATC model, is described in section 2.3. The experiment model and legacy software models themselves are described in more detail in section 4 and appendices B, C, and D. A direct comparison was made between experiment needs (represented by the experiment model) and legacy software capabilities (represented by legacy software models), and some conclusions were drawn concerning the ability of legacy software to meet experiment needs. The comparison of the experiment model with the legacy software models is shown formally in section 4.3.

    The remainder of section 2 contains the following:

    • Modeling concepts, including model components and notation (section 2.2)

    • Model usage (section 2.3)

    • Implications for object-oriented design (section 2.4)

    The concept of OOA described in this paper is a consolidation of ideas from many sources, especially (Coad and Yourdon, 1991) and (Booch, 1991), augmented with original ideas sparked by the domain of interest. Unless stated otherwise, a reference to Coad or to Booch is a reference to (Coad and Yourdon, 1991) or to (Booch, 1991), respectively.

2.2 MODELING CONCEPTS

A result of an object-oriented analysis is a model of the domain. The building blocks of a model include subjects, classes, objects, structures, instance connections, message connections, and views. Detailed information about a model is contained in the model specification.

Figure 2-3 provides notation for the subject, class, object, attribute, service, instance connection, and message connection concepts described below. This notation is adapted from (Coad and Yourdon, 1991). Other notations are introduced below as needed. This paper also adopts the convention that the name of a model component (e.g., a class) is spelled with initial capital letters (e.g., the Aircraft class) and the name of a real-world instance of that component is spelled with lower case letters (e.g., the aircraft).

Figure 2-4 is part of a model which is used throughout this section to provide examples of concepts as they are introduced.

Unless otherwise stated, the conventions and terminology discussed in this section are those adopted for the methodology used by the task.

Figure 2-2. The Object-Oriented Analysis Task

Figure 2-3. Model Notation

Figure 2-4. Examples of Model Components

2.2.1 Classes and Objects

An object is an abstraction of a real or theoretical entity, and is described by its attribute values and exclusive services. (From a programming point of view, an object is a program module that contains both its data and its procedures for operating on that data - no more and no less.) The three intrinsic characteristics of an object are its state, its behavior, and its identity. The state of an object takes into account its static properties and the static or dynamic values of these properties. The behavior of an object describes how the object acts or reacts as its state changes or as it sends or receives messages. The identity of an object is that property that uniquely distinguishes it from all other objects.

For example, in figure 2-4, an Airspace Surveillance System object (e.g., a particular air route surveillance radar [ARSR] system) has one attribute, Area of Coverage, and one service, Locate, Identify & Report Flight. The states of such an object might be "on," off, " and "test." To illustrate change in behavior due to state change, the object would probably respond differently to the presence of an Aircraft object in its area of coverage (e.g., perhaps not at all) when the state is "test" versus when the state is "on."

When all objects in a collection have the same attributes and services, the term "class" is used to refer to them all collectively. For example, the set of all Airspace Surveillance System objects is represented by the Airspace Surveillance System class. An object can be considered to be a realization or an "instance" of a class, and the terms "object" and "instance" are frequently used synonymously. (Winblad, Edwards, and King, 1990) refers to classes as "static templates" and objects as "dynamic entities."

Although each object must belong to a class, it is not necessary for a class to have objects. An "abstract class" exists to provide structure for other classes; in one sense, its objects are really instances of its subclasses. In figure 2-3, the class called "Class" is an abstract class, indicated by the lack of a outer box. Each of the other classes can have objects. In figure 2-4, each of the classes pictured can have objects.

Coad believes that most classes and objects in a domain fall into the following categories:

In addition, other classes and objects can be derived from existing classes and objects by considering the following types of structures:

Structures are discussed in section 2.2.3.

Each object in a class can have its own value for each object attribute. According to (Shlaer and Mellor, 1988), the attributes of an object of a class fall into the following three categories:

Schlaer and Mellor also describe identifier attributes, which uniquely distinguish each object of a class. In this paper, it is assumed that the use of identifiers is deferred to the object-oriented design step, making such attributes "implicit", i.e., invisible as attributes for analysis purposes. This paper does admit descriptive attributes which appear to be identifiers (e.g., the attribute Aircraft Identification of an Aircraft object) but are not because uniqueness is not assured.

Services (or "operations") are the behaviors that a class or object is responsible for performing. Services take into account the different states of the object, when a change in attribute values causes a change in object behavior. Coad places required services into two general categories: algorithmically-simple services and algorithmically-complex services. Algorithmically-simple services include the following:

Each attribute and service is distinguished as being a class attribute or service or an object attribute or service; a class attribute is a quality of the class, not of an object, and a class service is a service performed by the class, not by one of its objects. For example, the service "create" is usually considered to be a class service rather than an object service: a class can create an instance (an object) of itself, but an object cannot directly create another object. An object can bring about the creation of another object by sending a message to the appropriate class, requesting that class to perform the service create.

Algorithmically-simple services are treated as "implicit" services, and are not shown explicitly in the model notation. For example, the notation for an Aircraft object in figure 2-4 is empty in the services (lower third) part, because (at least in this example) an Aircraft object has only algorithmically-simple services.

Algorithmically-complex services include services of the following types:

The service Locate, Identify & Report Flight service of an Airspace Surveillance System object in figure 2-4 is an algorithmically-complex service.

With respect to the data-control-process aspects of OOA (as described in section 2.1 above), process and data are hidden in classes and objects.

2.2.2 Instance Connections and Message Connections

Instance connections reflect associations between objects considered necessary because of timing or some other consideration. For example, figure 2-4 shown an instance connection between a Vehicle Surveillance System object and an Airspace Surveillance System object, created here because the aircraft is located in the area of coverage of the airspace surveillance system.

An instance connection between two objects reflects a constraint, in the form of an amount or range (also called the multiplicity) of mappings possible between the objects (e.g., exactly one connection must exist between two specific objects). An instance connection between two objects is defined in terms of one or more referential attributes. The multiplicity of an instance connection is shown in the model notation by numeric labels at each end of the instance connection line. A single number designates a fixed number of connections. A pair of numbers designates the lower and upper bounds of a range: when "0" is the lower bound, the connection is optional; when "m" is the upper bound, more than one connection is possible. For example, in figure 2-4, an aircraft is in the area of coverage of no, one or several airspace surveillance systems (represented by the "(0,m)" on the line between the Vehicle Surveillance System object and the Airspace Surveillance System object as the line joins the Airspace Surveillance System object) and there are no, one or several aircraft in the area of coverage of an airspace surveillance system (represented by the "(0,m)" on the line as it joins the Vehicle Surveillance System object).

A message connection between a class or object and another class or object represents a request that the latter entity (the receiver) perform a service for the former entity (the sender) and return a response. Message connections which would exist only to request implicit services (i.e., the algorithmically-simple services create, connect, access, and release) may also be treated implicitly (i.e., not shown explicitly) in the model notation. However, if considered necessary, such a message can be shown and labeled with the name of the implicit service spelled with lower case letters. For example, in figure 2-4, the message "access Location attribute" is a message sent by an Airspace Surveillance System object to an Aircraft object requesting the Aircraft object to perform its implicit service "access." The message Request Altitude Report is sent from an Airspace Surveillance System object to a Vehicle Surveillance System object to request the latter to perform its algorithmically-complex service Report Altitude.

With respect to the data-control-process aspects of OOA (as described in section 2.1 above), control is represented by messages between classes or objects.

2.2.3 Structures

Structure helps to clarify and reduce the complexity of a system under study. Two types of structures are recognized: generalization-specialization structures (Booch's "kind of" hierarchy called the "class structure"), and whole-part structures (Booch's "part of" hierarchy called the "object structure").

A generalization-specialization structure defines relationships between classes. A class is a generalization of a second class when the attributes and services of the first class all belong also to the second class. The second class is considered a specialization of the first class, and may contain additional attributes and services not belonging to the first class. The specialization class is said to inherit its attributes and services from the generalization class. In figure 2-4, the Transponder class is a specialization of the Vehicle Surveillance System class, and the Vehicle Surveillance System class is a generalization of the Transponder class. A Transponder object can perform the service Report Altitude because that service is inherited.

A generalization-specialization structure can be either a hierarchy (e.g., one generalization class with its specialization classes beneath it) or a lattice (e.g., more than one generalization class having one or more specialization classes in common). Booch uses the term "base class" for the generalization class.

A whole-part structure defines relationships between objects. An object is a whole object in a whole-part structure with a set of one or more part objects if the whole object can be considered to be made up of, or a container for, or a collection of, the part objects. There is no implicit relationship between the attributes and services of the whole object and those of a part object. A whole-part relationship also includes a multiplicity of relationships possible, similar to the multiplicity of instance connections. For example, in figure 2-4, an Aircraft object has no, one or several Vehicle Surveillance System objects as parts. A whole object usually has several part objects, whether from the same class (as in the figure) or from several different classes.

The collection-member form of the whole-part structure is especially useful for mental model abstractions, when either the "whole" or "part" is a concept rather than a "touchable" entity. For example, in ATC, it is useful to think of a Flight object with part objects Aircraft, Flight Plan, and Flight Clearance. Only the Aircraft object is always touchable. A Flight Plan object might begin as touchable (e.g., a filed piece of paper) but quickly becomes only an electronic image. A Flight Clearance object represents an accumulation of verbal or electronic communications, each of which is at best an electronic image.

Generalization-specialization structures and whole-part structures can be combined together in versatile ways to represent more complex structures. Some examples of mixed structures include the following:

The last example above also illustrates a powerful side effect of some mixed structures: the inheritance of structure. Figure 2-5 shows that the Route class is a generalization class with the four specialization classes Jet Route, Airway, Area Route, and Military Training Route, and a Route object is a whole object with two part objects, Fix/Waypoint and Route Segment. Each of the specialization classes inherit the whole-part structure of the Route object; e.g., an Airway object is also made up of one or more Fix/Waypoint objects and one or more Route Segment objects.

Figure 2-5. Inheritance of Whole Part Structure

2.2.4 Subjects

A subject is a grouping of one or more related structures. A large, complex model might be organized into a small number of subjects, in order to simplify the presentation of basic concepts about the model. No subjects are shown in figure 2-4, but if the figure represented a complete model, two subjects called "Aircraft" (representing the structure containing the Aircraft class and object) and "Surveillance" (representing the class and object Airspace Surveillance System) might be considered. In this way, a presenter could talk about the interactions of Surveillance and Aircraft without worrying about what specific component within the Aircraft subject actually performed a service.

2.2.5 Views

Views are used to focus upon the limited subset of a model involved in a particular object state change, event, or sequence of events. Only pertinent details are shown; all other details are hidden.

Views usually show interactions among subjects. A typical view contains at least two objects (usually three or more selected from two or more of the subjects), only the instance connections needed by the view, two or three message connections, and only the attributes needed by the instance connections and the services requested by the message connections. Views are graphically arranged with subject components occupying the same relative positions in each view. Instance connections that exist at the beginning of an event being considered are shown by a solid line, whereas instance connections that are created dynamically during the event are shown by a dashed line. When the multiplicity of each instance connection is "1" for each involved object, it need not be shown. A message that requests an implicit service is shown with lower case letters to emphasize that it is considered an implicit message. A message between two classes or objects that allows two implicit services to interact need not be shown in a view.

An illustration of a typical view is shown in figure 2-6. This view contains a class and object from each of three subjects in a model. The views in this model always place the Manager subject components at the lower left of the view, the Resource subject components at the top middle, and the User subject components at the lower right.

The event illustrated is a request by a user-type object to use a resource-type object, and the resulting reactions. It is assumed that the user-type object does not now have permission to use the resource-type object; otherwise (in this model), an instance connection would exist between the user-type object and the resource-type object illustrating that the user-type object is taken into account in the Demand attribute of the resource-type object. The instance connection between the resource-type object and the manager-type object shows that there is only one resource-type object of interest, but possible several manager-type objects (e.g., there may be several ground controllers associated with a particular airport movement area). The instance connection between the user-type object and the manager-type object shows that there is exactly one user-type object and exactly one manager-type object in this view.

Figure 2-6. View

The user-type object, in performing the service Plan Resource Usage, sends a message to the manager-type object; which manager-type object receives the message is determined by the instance connection between the user-type object and the manager-type object. The manager-type object accesses the attributes Demand, Saturation Threshold, and Usage Restrictions of the resource-type object before making a decision. Finally, the manager-type object returns a response to the user-type object; the response is not shown explicitly, because it is assumed that the original message will have a response. Assuming that the request was granted by the manager-type object, the user-type class needs to add an instance connection between the user-type object and this resource-type object. This instance connection is shown as a dashed line to emphasize that the connection is created dynamically as a result of this event. The connect service of the resource-type object reacts to the addition of the instance connection by causing the Update Demand service of the resource-type object to be performed.

The view notation was constructed by the authors using parts of Coad's notation and some invented notation (e.g., the dashed line representing a dynamically-created instance connection).

2.2.6 Model Specification

A set of specifications is provided for each model. The specifications are ordered by class name and include the following:

The form of the model specification is a variation of the specification described in (Coad and Yourdon, 1991).

2.3 MODEL USAGE

The models described in this paper were composed for the reasons stated in section 1.2. The ATC model (described in section 3.2) is both a model of the ATC system and a template which helps to describe parts (or proposed parts) of the ATC system with reference to the complete system.

This paper focuses on models of the ATC system. This paper does not attempt to describe an "I-Lab model," where the I-Lab itself is taken as the domain of study. An I-Lab model would have other components, corresponding to scenario generation, experiment control, experimental subject interface, and results extraction.

2.3.1 Reference Model

To use the ATC model as a reference model for an experiment or for legacy software (the "problem domain"), the modeler first identifies the components (e.g., classes, instance connections) of the problem domain using the components of the ATC model as the initial set of candidates. For example, the problem domain may reuse the class "Flight" from the ATC model. On the other hand, when there is no corresponding component in the ATC model, the modeler is free to add a problem-domain-unique component. For example, the problem domain may need a class "Current Plan" which does not exist in the ATC model. (The ATC model class "Flight Plan" is close to, but not the same as, the class "Current Plan.") The model notation for a problem domain model is modified to show the problem domain model's dependence on the ATC model. In a problem domain model, the "borrowed" ATC model components are shown with a shaded background, and problem domain component names unique to the problem domain are not. Some ATC model components are included to provide structure for the problem domain model, even though the problem domain might not have a component of the same name.

2.3.2 Evaluation of Experiment vs. Legacy Software

The first step in using the ATC model in an evaluation of experiment requirements vs. legacy software capabilities is to use the ATC model as a reference model as described in section 2.3.1 above. Once an experiment model and one or more legacy software models have been defined using the ATC model as a common template, the experiment model can be compared directly with the legacy software models to see if the legacy software can be used to carry out the experiment. The comparison is done by component (e.g., experiment class vs. legacy software class, experiment view vs. legacy software view). When an experiment component has no matching legacy software component, the legacy software alone is not sufficient to carry out the experiment. When two components match, the experimenter can further evaluate the suggested legacy software component to see if it can be used. For example, the legacy software component may be exactly what the experimenter had in mind, or it may need minor additions or subtractions in functionality, or it may carry along with it additional "unneeded" functionality which must be evaluated as extra overhead in the experiment. When the experiment model is compared with several legacy software models simultaneously, it is also possible that the legacy software models themselves overlap with each other or that each legacy software model provides only part of the functionality needed by the experiment, with no one of them sufficient for the experiment by itself. In this case, decisions must be made concerning how to use the legacy software (e.g., modify each one, augment one with the other's needed functionality, rewrite).

2.3.3 Extensibility and Reusability

In section 2.4.2, an implicit assumption is made that the experiment and legacy software are "looking at" ATC from the same point of view as the ATC model. Using the ATC model as a reference model primarily involved selecting existing classes and objects and creating specializations of them. However, the ATC model should be "reusable" for other modeling efforts with different points of view. Many classes and objects (e.g., Aircraft, Airspace) should be commonly needed regardless of the point of view; it might be possible to use their attributes and services "as is," modified, or augmented. For example, the ATC model does not now include the concept of an ATC facility; the "parts" of a facility are available, but they are not related in a way that would be meaningful to someone interested in facilities. A facility object could be defined as made up of the appropriate existing part objects selected from manager-, airspace/ground-, surveillance-, navigation-, communications-, and weather-type objects. Thus, with a new whole-part structure, the ATC model could be extended to include the concept of facility.

2.4 IMPLICATIONS FOR OBJECT-ORIENTED DESIGN

The ATC model (and hence the models based upon it) has some classes which are closely related (see section 3.2.3). Booch discusses the concept of "friend," which he defines as a "method [service] typically involving two or more objects of different classes, whose implementation for any one class may reference the [normally hidden] parts of all the corresponding classes that are also friends." Because of the tight coupling, it might be appropriate to consider the use of friends in any design based upon the models in this paper.

In addition, if legacy software is to be kept "intact," it may be necessary to link the common components in some way. For example, each legacy software model contains an Aircraft class. The use of friends may be the answer here also.

HOME