Home

 

Getting Started with Elisa

Using EDS

Demo's

Tutorials

 

Language Description

1. Lexical Elements
2. Basic Data Types and Expressions
3. Definitions
4. Streams
5. Backtracking
6. Statements and Special Expressions
7. Arrays
8. Lists
9. Descriptors
10. Components
11. Collections
12. Generic Components
13. Terms
14. Categories
15. Types 

16. Built-in Definitions
17. Higher-order Definitions

18. External Interfaces

Index

Data Structures

1. Sequences
2. Examples involving Lists
3. Trees
4. Graphs
5. Searching State Spaces
6. Language Processing
7. Knowledge Representations          

 

Metaprogramming

1. Introduction
2. What are Domain Definitions?

3.  Sorts of Domain Definitions

4.  Manipulations of Domain Definitions

5.  Translating Domain Definitions

6.  Dialogue Sessions

7.  Example of Concentric Circles

8.  Example of Domain Substitution applied to Concentric Circles

9.  Example of an Order Processing Application

10.Example of an Airport Information System

11.Example of a Rental Boat Business

12.Benefits of Domain Definitions

   

Back Home Up Next


8 CASE STUDY: AN AIRPORT SUPPORT SYSTEM

8.1 Step 1: Key Concepts of an Airport Support System
8.2 Step 2: Domain Definitions for Key Concepts 
8.3 Step 3: Domain Operations
                    8.3.1 Flight Domain Operations
                    8.3.2 Time Domain Operations
                    8.3.3 Gate Domain Operations
                    8.3.4 Operations for Repetitive Domains
8.4 Step 4: Domain Implementations
                    8.4.1 Flight Component
                    8.4.2 Time Component
                    8.4.3 Gate Component
                    8.4.4 Lists Component
                    8.4.5 Coupler Component
8.5 Step 5: Defining the System
                    8.5.1 Specifying System Operations
                    8.5.2 System Implementation
8.6 Testing the model

 

In the chapter we will discuss how to develop a domain model for an airport support system. As with any case study, also this one is grossly oversimplified and gives only a very limited view of some airport operations.

In this case study, we will develop a model of how incoming flights are assigned to gates and how passengers, airport personnel, and airport visitors are informed about arrivals and departures. As we discuss a domain model, we will not include in our model communication functions and hardware facilities which are neccessary for an operational system. We will use the same modeling steps as described in previous chapters.

 

8.1 Step 1: Key Concepts of an Airport System

To discover the key concepts of an airport support system we start by drawing a very simple picture of an airport in its environment:


-----------         -----------         -----------
| ------------      |         |      ------------ |
| |          |      |         |      |          | |
| | Incoming |      | Airport |      | Outgoing | |
| | Flights  | ===> |         | ===> | Flights  | |
| |          |      |         |      |          | |
  |          |      |         |      |          |
  ------------      -----------      ------------

Figure 8-1: The Environment of an Airport

From this simple diagram we may conclude that for an airport the most important concepts are:

Incoming Flights

Outgoing Flights

This may be even simplified to one key concept:

Flight

which we will use in the following. And that is sufficient for the first step.

 

8.2 Step 2: Domain Definitions for Key Concepts

For a key concept we need to write a domain definition. In our case it means that we have to define a flight. We know from experience that a flight is characterized by a flight number, the name and type of an airplane, the origin and destination, a crew, passengers, and possibly cargo. To keep our model simple, we will assume that our flights are not tranporting cargo, and that there is no need for a list of crew members and a passengers list. Because we are only interested in information about arrivals and departures we may use as a first approximation the information as found in the timetable of an airline company and the information supplied by the arrival and departure displays at an airport. So, we will define a flight as:

flight = flightno + origin + destination + departuretime + arrivaltime + delay + [gate]

This domain definition defines a flight based upon its anticipated use. Later on, as we proceed, there may be a need to change this domain definition. (It is debatable if the gate information should be part of the flight domain. We do it here to keep our model simple, as will become clear after the definitions for displaying the arrivals and the departures).

As a next step we may now define the domains at the right hand side of the definition:

flightno             	= text
origin                	= airport
destination       	= airport
departuretime 	= time
arrivaltime      	= time
delay                  	= time

The domains which are not predefined domains should be defined further. In this example those domains are:

airport             	= text
time                    	= hour + minutes

The hour and minutes domains need further definition:

hour                 	= integer
minutes               	= integer

Another domain we need to define is that of a gate:

gate = gatename + [flightno]

Each gate has a name. A flight number may optionally be associated with a gate. The domain of a gatename is:

gatename = text

And herewith we have finished the definition of a flight. Furthermore we need a list of all the gates of an airport, and
a list of arrivals and departures:

gatelist       	= { gate }
arrivals       	= { flight }
departures 	= { flight }

And this completes our information model. An overview of all the domain definitions is given in Figure 8-2.


flight = flightno + origin + destination + departuretime + arrivaltime + delay + [gate]

flightno             	= text
origin                	= airport
destination       	= airport
departuretime 	= time
arrivaltime      	= time
delay                  	= time
airport             	= text
time                    	= hour + minutes
hour                 	= integer
minutes               	= integer
gate                   	 = gatename + [flightno]
gatename          	 = text
gatelist                 	= { gate }
arrivals                	= { flight }
departures         	= { flight }

Figure 8-2: Overview of Domain Definitions

And this concludes the second modeling step.

 

8.3 Step 3: Domain Operations

The following step is to specify the operations for the composite domain definitions. Our information model contains three composite domains: flight, time, and gate. Although some operations may be determined by their use, a number of operations can already be specified now. For each composite domain we have to specify a constructor operation, a number of accessor operations, and some state-changing mutator operations.

8.3.1 Flight Domain Operations

We start with the operations for the flight domain:

flight = flightno + origin + destination + departuretime + arrivaltime + delay + gate

The first operation is the constructor operation. It specifies what information is needed to make a flight a flight. In our case we say that a new flight can be defined if a flight number, an origin, a destination, a departure time, and an arrival time are defined. Information about possible delay and about the gatename may not be specified with the introduction of a new flight, they should be supplied later. So, our flight constructor operation has the following form:

flight (flightno, origin, destination, departuretime, arrivaltime) -> flight;

The basic accessor operations are easy, as we explained in Chapter 4, "Domain Operations". For each element of the flight domain we specify a corresponding accessor operation:

flightno (flight)      -> flightno;
origin (flight)        -> origin;
destination (flight)   -> destination;
departuretime (flight) -> departuretime;
arrivaltime (flight)   -> arrivaltime;
delay (flight)         -> delay;
gate (flight)          -> optional (gate);

Note that the last operation may produce an optional result.

Flight mutator operations are changing the state of a flight. We will assume that we only need two mutator operations: one to change the delay value and another to change the gate of a flight:

change_delay (flight, delay) -> nothing; 
change_gate (flight, gate)   -> nothing;

Both operations are changing the corresponding elements of the flight domain and both are returning nothing. And these mutator operations conclude the list of operations specified for the flight domain.

 

8.3.2 Time Domain Operations

The following compound domain is the time domain:

time = hour + minutes

The constructor operation for the time domain is straight forward:

time (hour, minutes) -> time;

The basic accessor operations are:

hour (time)    -> hour;
minutes (time) -> minutes;

We assume that it is not necessary to change the hours and minutes of the time domain. Consequently, there is no need to introduce mutator operations for the time domain.

However, we do expect that there will be a need to add two time domains, for example, to compute the expected arrival time as the sum of the scheduled arrival time and the delay time. We also assume that there will be a need to compare two time domains to determine if a given point in time is earlier or later than another point in time. So, two behavior related operations are needed:

time + time -> time;
time < time -> boolean;

And these operations are the final ones for the time domain.

 

8.3.3 Gate Domain Operations

The last composite domain of our information model is the gate domain:

gate = gatename + [flightno]

Because a flight is only temporarily attached to a gate, the gate constructor operation can be very simple:

gate (gatename) -> gate;

The accessor operations for a gate domain are:

gatename (gate) -> gatename;
flightno (gate) -> optional (flightno);
occupied (gate) -> boolean;

The reason for the last operation is that a flight may optionally be associated with a gate, thus an operation is needed to test if a gate is occupied.

Two mutator operations will be defined for a gate domain: one to assign a flight to a gate, and another to clear a gate:

assign (flightno, gate) -> nothing;
clear (gate)            -> nothing;

Although the skeleton for optional domains (see Figure 5-5) suggests different names for these kinds of operations we have chosen to use here more behavior related names.

 

8.3.4 Operations for Repetitive Domains

For the following domains:

gatelist       	= { gate }
arrivals       	= { flight }
departures 	= { flight }

we assume that the operations defined for individual repetitive domains, as defined in Section 5.6.2, are available.

And this concludes the third modeling step.

 

8.4 Step 4: Domain Implementations

The next step is to define implementations for the domain specifications. We start with the composite domains: flight, time, and gate. Each composite domain is represented by a corresponding component according to the skeletons described in Chapter 5.

 

8.4.1 Flight Component

We start with the definition of a component for flights:

component Flights;
type flight;
     flight (flightno, origin, destination, departuretime, arrivaltime) -> flight;
     flightno (flight)            -> flightno;
     origin (flight)              -> origin;
     destination (flight)         -> destination;
     departuretime (flight)       -> departuretime;
     arrivaltime (flight)         -> arrivaltime;
     delay (flight)               -> delay;
     gate (flight)                -> optional (gate);
     change_delay (flight, delay) -> nothing; 
     change_gate (flight, gate)   -> nothing;
begin
     flight (flightno, origin, destination, departuretime, arrivaltime) =
              flight:[flightno; origin; destination; departuretime; arrivaltime; 
                                          delay = time (0, 0); gate = null (gate) ];
     flightno (flight)            = flight.flightno;
     origin (flight)              = flight.origin;
     destination (flight)         = flight.destination;
     departuretime (flight)       = flight.departuretime;
     arrivaltime (flight)         = flight.arrivaltime;
     delay (flight)               = flight.delay;
     gate (flight)                = flight.gate when flight.gate <> null (gate);
     change_delay (flight, delay) = [ flight.delay:=delay];
     change_gate (flight, gate)   = [ flight.gate:=gate];
end component Flights;

The interface section of the Flights component contains a type specification and operation specifications as derived in the preceding sections about the flight domain.

The implementation section defines the operations as specified in the interface section. For example, the constructor operation defines the layout and the contents of a flight-descriptor. The layout of the flight-descriptor is similar to the structure of the flight domain definition. The contents of the descriptor elements which are not defined by the constructor function, such as delay and gatename are introduced with default values.

All the other definitions are simple implementations of the specified operations for the flight domain.

 

8.4.2 Time Component

The next composite domain is the time domain. A component for time is defined as follows:

component Times;
type hour    = integer;
type minutes = integer;
type time;
     time (hour, minutes) -> time;
     hour (time)          -> hour;
     minutes (time)       -> minutes;
     time + time          -> time;
     time < time          -> boolean;
begin
     time (hour, minutes) = time:[ hour; minutes ];
     hour(Time)    = Time.hour;
     minutes(Time) = Time.minutes;
     Time1 + Time2 = [ Hour:= Time1.hour + Time2.hour;
                       Minutes:= Time1.minutes + Time2.minutes;
                       Hour:= Hour + Minutes / 60;
                       Minutes:= mod (Minutes, 60);
                       time (Hour, Minutes) ]; 
     Time1 < Time2 = 60 * Time1.hour + Time1.minutes < 
                     60 * Time2.hour + Time2.minutes;
end component Times;

The definitions for the time domain operations are self-explanatory. Note, that there are no provisions for midnight changes!

 

8.4.3 Gate Component

The component for the gate domain is defined as:

component Gates;
type gatename = text;
type gate;
     gate (gatename)         -> gate;
     gatename (gate)         -> gatename;
     flightno (gate)         -> optional (flightno);
     occupied (gate)         -> boolean;
     assign (flightno, gate) -> nothing;
     clear (gate)            -> nothing;
begin
     gate (gatename) = gate:[ gatename; flightno = "" ];
     gatename (gate) = gate.gatename;
     occupied (gate) = gate.flightno <> "";
     flightno (gate) = gate.flightno when occupied (gate);
     assign (flightno, gate) = [gate.flightno:=flightno];
     clear (gate) = [gate.flightno:=""];
end component Gates;

The definitions of the gate domain are straight forward. Note, that we are using as default value for the gatename an empty text value, instead of a null (flightno), as indicated in the skeleton of Figure 5-5. The reason is that an empty text value can easily been displayed.

 

8.4.4 Lists Component

For the repetitive domains:

gatelist       	= { gate }
arrivals       	= { flight }
departures 	= { flight }

a polymorphic component, derived from the skeleton for individual repetitive domains (see Figure 5-9), will be used:

component Lists;
type List = list (Element);
type Element = entity1;
type ID = text;
     Elements (List)             -> multi (Element);      << accessor operations >>
     Element (List, ID)          -> optional (Element);
     add_Element (List, Element) -> nothing;              << mutator operations >>
     remove_Element (List, ID)   -> optional (Element);
begin
        << accessor operations: >>
     Elements (List) = items (List);
     Element (List, ID) = [ [ CI = items (List);
                              if ID (CI) == ID then return (CI) ];
                            message ("Unknown ID: ", ID);
                            no (Element) ];
        << mutator operations: >>
     add_Element (List, Element) =
                  [ ID = ID (Element);
                    [ CI = items (List);
                      if ID (CI) == ID then [ message ("Existing ID: ", ID); return ] ];
                    add (List, Element) ];
     remove_Element (List, ID) = 
                  [ [ CE = nodes (List);
                      if ID (item (CE)) == ID then return (remove (CE)) ]; 
                    message ("Unknown ID: ", ID);
                    no (Element) ];
end component Lists;

The connections of the component with its environment are defined by the coupler component.

 

8.4.5 Coupler Component

The coupler component for the airport support system provides the type definitions for the equivalent domain definitions, the definition for the ID function as required by the polymorphic Lists component, and the general message definition:

component CouplerAirportSupportSystem;
type flightno      = text;
type origin        = airport;
type destination   = airport;
type departuretime = time;
type arrivaltime   = time;
type delay         = time;
type airport       = text;
     ID (Element) -> text;
     message (text, entity1) -> nothing;
begin
    ID (Element)  -> text;
    ID (flight: F) = flightno (F);
    ID (gate: G)   = gatename (G);
    message (text, entity1) -> nothing;
    message (T, E) = logln(Message (T, E)); 
    Message (text, entity1) => term;
end component CouplerAirportSupportSystem;

And this concludes the fourth step.

 

8.5 Step 5: Defining the System

The following step is to define the system. As described in Chapter 6, this step consists of two sub-steps. The first activity is to determine the system operations. The second activity is to define implementations of these system operations.

8.5.1 Specifying System Operations

System operations are based on external events. We saw already that the environment of the airport is determined by incoming and outgoing flights (see Figure 6-1). Our airport support system is part of the airport operations.

As we described in Chapter 6 about "Systems", we first have to define the external events which are influencing the airport support system. For example, flights coming from other airports, should be registrated by our system. We may expect that those flights are announced sufficiently ahead of the expected arrival time by the airport of departure or by the airplane itself. Such an announcement is an external event for the airport support system. Another external event is the announcement of a delay of an incoming flight. In general, after a flight has been announced, multiple delay announcements are possible. Another external event is the assignment of a gate to an aircraft.

In our model the following external events are expected by our airport support system:

1. Announcement of an incoming flight

2. Delay of an incoming flight

3. Gate assignment for an incoming flight

4. Announcement of an outgoing flight

5. Delay of an outgoing flight

6. Gate assignment for an outgoing flight

7. Gate release for next flight

8. Request to update the Arrivals display

9. Request to update the Departures display

10. Request to provide a systems overview

These external events are translated into corresponding system operations. Because we are only modeling an airport support system for one airport we may neglect the airport type parameter in the system operations. The corresponding system operations are:

Arrival (flight) -> nothing;

ArrivalDelayed (flightno, delay) -> nothing;

AssignGateForArrival (flightno) -> optional (gatename);

Departure (flight) -> nothing;

DepartureDelayed (flightno, delay) -> nothing;

AssignGateForDeparture (flightno, gatename) -> nothing;

ReleaseGate (gatename) -> nothing;

Arrivals ( ) -> multi (text);

Departures ( ) -> multi (text);

Overview ( ) -> list (term);

And this concludes the first task to determine the system operations of our airport support system.

 

8.5.2 System Implementation

The second task is to define an implementation of the system.

Before the system operation specifications can be translated into corresponding definitions, we first need to determine the kinds of information that will be kept by the system. As input we use again the repetitive domains of our information model:

gatelist       	= { gate }
arrivals       	= { flight }
departures 	= { flight }

These domain definitions are translated into corresponding lists:

gatelist = { gate ( ("Gate1","Gate2") ) };
arrivals = alist (flight);
departures = alist (flight);

Initially the list of arrivals and the list of departures are both empty (this is comparable with a new airport which has just been opened). However, the gatelist should contain descriptions of all the gates of the airport. In our example, we assume that there are only two gates, called Gate1 and Gate2.

These three lists together are forming the database of the system:

database = {term: gatelist, arrivals, departures};

We are now already able to define the Overview operation from the system operation list:

Overview ( ) = database;

The Overview operation simply returns the database of the system.

Let us now try to define some other system operations. We will start with the first one which announces a new incoming flight:

Arrival (flight) -> nothing;
Arrival (Flight) = add_Element (arrivals, Flight);

A new arrival will simply be added to the list of arrivals. Use is made of the add_Element operation of the Lists component, which will check if the flightno is unique.

The following operation is used in case an incoming flight is delayed:

ArrivalDelayed (flightno, delay) -> nothing;
ArrivalDelayed (Flightno, Delay) = change_delay (Flight (Flightno, arrivals), Delay);

This operation uses the change_delay operation as defined in the Flights component. However, before the operation can be performed, first the flight number must be used to search in the arrivals list for the incoming flight. This is done by a separate definition, called Flight. The Flight definition may search in any kind of flight list:

Flight (flightno, list (flight) ) -> optional (flight);
Flight (Flightno, FlightList) = Element (FlightList, Flightno);

It uses the Element operation of the Lists component. A message will be given if no flight has been found with the specified flightno.

Another system operation is the assignment of a gate for an incoming flight. In our system we assume that a free gate will be searched and that the assignment to the flight is done by the system:

AssignGateForArrival (flightno) -> optional (gatename);
AssignGateForArrival (Flightno) = 
        [ FreeGate = SearchFreeGate ( );
          assign (Flightno, FreeGate); 
          assign (gatename (FreeGate), Flight (Flightno, arrivals) );
          gatename (FreeGate) ];

A free gate is searched by the following definition:

SearchFreeGate ( ) -> optional (gate);
SearchFreeGate ( ) = [ [ Gate = items (gatelist);
                         return (Gate) when ~ occupied (Gate) ];
                       message ("No free gate available!", "");
                       no (gate) ];

It searches in the list of gates for an unoccupied gate.

The definitions for the operations of Departure, DepartureDelayed, and AssignGateForDeparture are similar to the corresponding Arrival operations.

Another set of interesting system operations are the requests to update the Arrivals and the Departures displays to inform the passengers and airport personel about coming arrivals and departures. Both definitions are using the appropriate flight information and are similar in structure. As an example, we use the Arrivals definition:

Arrivals ( ) -> multi (text);
Arrivals ( ) = 
  [ result ("                        ARRIVALS                             ");
    result (" Flight | Origin | Arrival Time | Delayed | Expected | Gate |");
    Flight = items (arrivals);
      field (10, flightno (Flight)) & 
      field (15, origin (Flight)) &
      field (17, text (arrivaltime (Flight))) &
      field (10, text (delay (Flight))) &
      field (11, text (arrivaltime (Flight) + delay (Flight))) &
      field (07, gatename (gate (Flight))) ];

The first two lines are used to generate the headings of the list. Then, for each flight in the arrivals list the corresponding fields are filled. The meaning of a field is defined by a separate definition. Another definition is needed to convert a given time description to the conventional textual representation such as 10:45.

All the system operations are implemented in the following component:

component AirportSupportSystem;
   Arrival (flight)                            -> nothing;
   ArrivalDelayed (flightno, delay)            -> nothing;
   AssignGateForArrival (flightno)             -> optional (gatename);
   Departure (flight)                          -> nothing;
   DepartureDelayed (flightno, delay)          -> nothing;
   AssignGateForDeparture (flightno, gatename) -> nothing;
   ReleaseGate (gatename)                      -> nothing;
   Arrivals ( )                                -> multi (text);
   Departures ( )                              -> multi (text);
   Overview ( )                                -> list (term);
begin
   gatelist   = { gate ( ("Gate1","Gate2") ) };
   arrivals   = alist (flight);
   departures = alist (flight);
   database = { term: gatelist, arrivals, departures };
   Overview ( ) = database;
   Arrival (flight) -> nothing;
   Arrival (Flight) = add_Element (arrivals, Flight);
   ArrivalDelayed (flightno, delay) -> nothing;
   ArrivalDelayed (Flightno, Delay) = change_delay (Flight (Flightno, arrivals), Delay);
   AssignGateForArrival (flightno) -> optional (gatename);
   AssignGateForArrival (Flightno) = 
                     [ FreeGate = SearchFreeGate ( );
                       assign (Flightno, FreeGate); 
                       assign (gatename (FreeGate), Flight (Flightno, arrivals) );
                       gatename (FreeGate) ];
   Departure (flight) -> nothing;
   Departure (Flight) = add_Element (departures, Flight);
   DepartureDelayed (flightno, delay) -> nothing;
   DepartureDelayed (Flightno, Delay) = change_delay (Flight (Flightno, departures), Delay);
   AssignGateForDeparture (flightno, gatename) -> nothing;
   AssignGateForDeparture (Flightno, GateName) = 
                     [ assign (Flightno, Gate (GateName));
                       change_gate (Flight (Flightno, departures), Gate (GateName) ) ];
   ReleaseGate (gatename) -> nothing;
   ReleaseGate (Gatename) = clear (Gate (Gatename));
   Arrivals ( ) -> multi (text);
   Arrivals ( ) = 
      [ result ("                        ARRIVALS                             ");
        result (" Flight | Origin | Arrival Time | Delayed | Expected | Gate |");
        Flight = items (arrivals);
          field (10, flightno (Flight)) & 
          field (15, origin (Flight)) &
          field (17, text (arrivaltime (Flight))) &
          field (10, text (delay (Flight))) &
          field (11, text (arrivaltime (Flight) + delay (Flight))) &
          field (07, gatename (gate (Flight))) ];
   Departures ( ) -> multi (text);
   Departures ( ) = 
      [ result ("                          DEPARTURES                                ");
        result (" Flight | Destination | Departure Time | Delayed | Expected | Gate |");
        Flight = items (departures);
          field (10, flightno (Flight)) & 
          field (15, destination (Flight)) &
          field (17, text (departuretime (Flight))) &
          field (10, text (delay (Flight))) &
          field (11, text (departuretime (Flight) + delay (Flight))) &
          field (07, gatename (gate (Flight))) ];
                                          << internal definitions: >>
   field (integer, text) -> text;             << aligns output field >>
   field (n, T) = [ Spaces:="";
                    [ i = 1 .. (n - size (T) - 2); Spaces:=Spaces & " "];
                    Spaces & T & " |" ];
   text (time) -> text;                       << converts time to text >>
   text (Time) = text (hour (Time), 2) & ":" & text (minutes (Time), 2);
   text (value=integer, width=integer) -> text;  <<converts integer to text>>
   text (Value, w) = [ Digits = array (character, w); V:=Value;
                       [ i = w + 1 - 1 .. w;
                           Digits[ i ]:= character (integer('0') + mod (V, 10) ); 
                           V:=V / 10 ];
                       Digits ];
   Flight (flightno, list (flight) ) -> optional (flight);
   Flight (Flightno, FlightList) = Element (FlightList, Flightno);
   SearchFreeGate ( ) -> optional (gate);
   SearchFreeGate ( ) = [ [ Gate = items (gatelist);
                            return (Gate) when ~ occupied (Gate) ];
                          message ("No free gate available!", "");
                          no (gate) ];
   Gate (gatename) -> optional (gate);     << search for gate with gatename >>
   Gate (Gatename) = [ [ Gate = items (gatelist);
                         return (Gate) when gatename (Gate) == Gatename ];
                       message ("Unknown gate name: ", Gatename);
                       no (gate) ];
end component AirportSupportSystem;

 

8.6 Testing the model

After we have built a domain model of the airport support system we can test the model. We will use various inputs and see what will happen. However, we first will compose our model from the components we already developed:

use Flights;
use Times;
use Gates;
use Lists;
use AirportSupportSystem;
use CouplerAirportSupportSystem;

These components are representing our domain model. The model may now be tested under various conditions.

We start using the Overview operation thereby asking what is initially in the database of a just opened airport:

Overview ( )?

The system returns with the state of the database:

{ { gate:[ gatename = "Gate1";
           flightno = "" ], 
    gate:[ gatename = "Gate2";
           flightno = "" ] }, 
  { }, 
  { } }

The response  is that only the gatelist has been filled with two gate descriptors. The list of arrivals and the list of departures are both empty.

Let us now assume that we try to model the airport of Denver and that an incoming flight from Paris is arriving:

Arrival (flight ("AF345","Paris","Denver", time (08, 15), time (11, 10) ) );

We can now again ask for the contents of the database:

Overview ( )?

The system returns with:

{ { gate:[ gatename = "Gate1";
           flightno = ""], 
    gate:[ gatename = "Gate2";
           flightno = ""]}, 
  { flight:[ flightno = "AF345";
             origin = "Paris";
             destination = "Denver";
             departuretime = time:[ hour = 8;
                                    minutes = 15 ];
             arrivaltime = time:[ hour = 11;
                                  minutes = 10 ];
             delay = time:[ hour = 0;
                            minutes = 0 ];
             gate = [ ] ] }, 
  { } }

The database contains beside the gatelist also one list element of the arrivals list: the flight descriptor for AF345.

The flight leader may now decide that for this flight a gate should be assigned:

AssignGateForArrival ("AF345")?
"Gate1"

The result is that Gate1 has been assigned to AF345.

Let us now assume that another incoming flight from Miami has to be entered into the system and that this flight has a delay of half an hour:

Arrival(flight ("DL607", "Miami", "Denver", time(10, 25), time(12, 45)) );
ArrivalDelayed ("DL607", time (0, 30) );

And also for this flight a free gate is requested by the flight leader:

AssignGateForArrival ("DL607")?
"Gate2"

So, Gate2 is assigned to DL607. The database contains now the following information:

{ { gate:[ gatename = "Gate1";
           flightno = "AF345"], 
    gate:[ gatename = "Gate2";
           flightno = "DL607"]}, 
  { flight:[ flightno = "AF345";
             origin = "Paris";
             destination = "Denver";
             departuretime = time:[ hour = 8;
                                    minutes = 15];
             arrivaltime = time:[ hour = 11;
                                  minutes = 10];
             delay = time:[ hour = 0;
                            minutes = 0];
             gate = gate:[ gatename = "Gate1";
                           flightno = "AF345"] ], 
    flight:[ flightno = "DL607";
             origin = "Miami";
             destination = "Denver";
             departuretime = time:[ hour = 10;
                                    minutes = 25];
             arrivaltime = time:[ hour = 12;
                                  minutes = 45];
             delay = time:[ hour = 0;
                            minutes = 30];
             gate = gate:[ gatename = "Gate2";
                           flightno = "DL607"] ] }, 
  { } }

The flight coordinator may now decide to display the arrivals:

Arrivals( )?

The result is:

"                          ARRIVALS                          "
" Flight | Origin | Arrival Time | Delay | Expected | Gate  |"
" AF345  | Paris  |   11:10      | 00:00 | 11:10    | Gate1 |"
" DL607  | Miami  |   12:45      | 00:30 | 13:15    | Gate2 |"

And this is what we may expect of a display of the arrivals.

Let us now assume that the airplane of AF345 at gate 1 will be used for flight AF346 to Seattle and that the airplane of DL607 at gate 2 will return to Miami as flight DL608. Because DL607 has a delay of 30 minutes, also the departure of DL608 will be delayed for 30 minutes. We may feed our model therefore with the following information:

Departure (flight ("AF346", "Denver", "Seattle", time(12, 25), time(13, 45)));
AssignGateForDeparture ("AF346", "Gate1");
Departure (flight ("DL608", "Denver", "Miami", time(14, 15), time(18,15)));
AssignGateForDeparture ("DL608", "Gate2");
DepartureDelayed ("DL608", time (0, 30));

If we are now asking for the contents of the database we get:

{ { gate:[ gatename = "Gate1";
           flightno = "AF346"], 
    gate:[ gatename = "Gate2";
           flightno = "DL608"]}, 
  { flight:[ flightno = "AF345";
             origin = "Paris";
             destination = "Denver";
             departuretime = time:[ hour = 8;
                                    minutes = 15];
             arrivaltime = time:[ hour = 11;
                                  minutes = 10];
             delay = time:[ hour = 0;
                            minutes = 0];
             gate = gate:[ gatename = "Gate1";
                           flightno = "AF346"] ], 
    flight:[ flightno = "DL607";
             origin = "Miami";
             destination = "Denver";
             departuretime = time:[ hour = 10;
                                    minutes = 25];
             arrivaltime = time:[ hour = 12;
                                  minutes = 45];
             delay = time:[ hour = 0;
                            minutes = 30];
             gate = gate:[ gatename = "Gate2";
                           flightno = "DL608"] ] }, 
  { flight:[ flightno = "AF346";
             origin = "Denver";
             destination = "Seattle";
             departuretime = time:[ hour = 12;
                                    minutes = 25];
             arrivaltime = time:[ hour = 13;
                                  minutes = 45];
             delay = time:[ hour = 0;
                            minutes = 0];
             gate = gate:[ gatename = "Gate1";
                           flightno = "AF346"] ], 
    flight:[ flightno = "DL608";
             origin = "Denver";
             destination = "Miami";
             departuretime = time:[ hour = 14;
                                    minutes = 15];
             arrivaltime = time:[ hour = 18;
                                  minutes = 15];
             delay = time:[ hour = 0;
                            minutes = 30];
             gate = gate:[ gatename = "Gate2";
                           flightno = "DL608"] ] } }

And a display of both the arrivals and the departures gives us the following information:

"                          ARRIVALS                          "
" Flight | Origin | Arrival Time | Delay | Expected | Gate  |"
" AF345  | Paris  |   11:10      | 00:00 | 11:10    | Gate1 |"
" DL607  | Miami  |   12:45      | 00:30 | 13:15    | Gate2 |"
"                          DEPARTURES                               "
" Flight | Destination | Departure Time | Delay | Expected | Gate  |"
" AF346  | Seattle     |     12:25      | 00:00 |   12:25  | Gate1 |"
" DL608  | Miami       |     14:15      | 00:30 |   14:45  | Gate2 |"

And this is what we expected from our domain model. So far, our model reacts according to our expectations.

Let us now examine how it behaves in case of abnormal or unusual inputs. For example, what happens when we ask for a gate for an unknown incoming flight, say KL444:

AssignGateForArrival ("KL444")?
Message ("No free gate available!", "")

This reaction is not what we may expect. The system should have responded with the message that KL444 is the name of an unknown flight.

What would happen if we assign a gate to a flight to which already a gate has been assigned?

AssignGateForArrival ("AF346")?
Message ("No free gate available!", "")

Also this reaction is not what we may expect. We would have expected a message which informs us that to AF346 already a gate has been assigned.

This brings us to another question: what happens if we introduce a flight which has already been entered into the system, such as:

Departure (flight ("DL608", "Denver", "Miami", time(15, 35), time(19,40)))?
Message ("Existing ID: ", "DL608")

This is a correct reaction because the system tells us that a flight with the flight number of DL608 is already known. If we now ask for all the departures, we get the following answers:

Departures ( )?
"                          DEPARTURES                               "
" Flight | Destination | Departure Time | Delay | Expected | Gate  |"
" AF346  | Seattle     |     12:25      | 00:00 |   12:25  | Gate1 |"
" DL608  | Miami       |     14:15      | 00:30 |   14:45  | Gate2 |"

This shows that the last departure flight has not been entered into the system, as it should be.

To conclude our model testing we learned from experimenting with our model that a number of common cases are working according to our expectations but that unsual inputs are not handled correctly. So, a next version of our model should contain facilities for these kinds of inputs. We will leave that as an exercise for the reader.

Top of Page   Part 4: Domain Modeling   Chapter 8: Case Study: An Airport Support System

            
Introduction

Home | Highlights of Elisa | Integrating Different Paradigms | Getting Started with Elisa | Demo's  | What is Domain Orientation | Bibliography | Copyright | News | Contact | Contents

Language Description:

Lexical Elements | Basic Data Types and Expressions | Definitions | Streams | Backtracking | Statements and Special Expressions | Arrays | Lists | Descriptors | Components | Collections | Generic Components | Terms | Categories | Types | Built-in Definitions | Higher-order Definitions | External Interfaces | Index 

Data Structures: Sequences | Examples involving Lists | Trees | Graphs | Searching State Spaces | Language Processing | Knowledge Representations
Domain Modeling:

Domain Modeling | Concepts | Domain Definitions | Domain Operations | Domain Implementations | Systems | Case study: an Order processing system | Case study: an Airport Support system | Domain Orientation versus Object Orientation

Design Patterns:

Introduction | Abstract Factory | Builder | Factory Method | Prototype | Singleton | Adapter | Bridge | Composite | Decorator | Facade | Flyweight | Proxy | Chain of Responsibility | Command | Interpreter | Iterator | Mediator | Memento | Observer | State | Strategy | Template Method | Visitor 

 

click tracking

This page was last modified on 27-09-2012 16:52:21   

free hit counter