Case Study part 1: from UML to JavaIM103 week 11 Part 1 p506

Learning objectives

By the end of this lecture you should be able to:

specify system requirements by developing a use case model;

annotate a composition association on a UML diagram;

develop test cases from behaviour specifications found in the use case model.

System overview

The application that we will develop will keep track of planes using a particular airport. So as not to over complicate things, we will make a few assumptions

there will only be four runways at the airport; there will be no concept of gates for arrival and departure,

passengers will be met at a runway on arrival and sent to a runway on departure;

planes entering airport airspace and requesting to land are either given permission to land on a free runway, or are told to join a queue of circling planes until a runway becomes available;

no planes are housed at the airport; planes boarding and subsequently requesting take-off must therefore have previously landed at the airport;

once a plane departs from the airport it is removed from the system; the detail of arrival and departure times will not be addressed.

A common way to document requirements in UML is to develop a use case model.

A use case model consists of use case diagrams and behaviour specifications.

A use case diagram is a simple way of recording the roles of different users within a system and the services that they require the system to deliver.

Once a list of use cases has been identified, behaviour specifications are used to record their required functionality

Requirements analysis and specification

use case diagram for the airport application

Register flight with airport

Record flight’s request to land

arrival

Record flight landing

Record flight take off

Airport Information

Officer

Air traffic controller

Allow passengers to board

List arrivals

List departures

Initial analysis of the airport application.

Runway

numberallocated

book()vacate()isAllocated()

Plane

flightNumbercityOfOriginstatus

upgradeStatus()

0..10..1

permitted to land on

Runway

number: intallocated: boolean

book()vacate()isAllocated(): boolean

Plane

flightNumber: StringcityOfOrigin: Stringstatus: int

theRunway:Runway

upgradeStatus()

0..10..1

permitted to land on

Initial design of the Plane and Runway classes.

Airport

-list: PlaneList-runway: Runway[]+RUNWAY_TOTAL:int = 4

+Airport()+registerFlight(String, String)+arriveAtAirport(String): int+landAtAirport(String)+readyForBoarding(String, String)+takeOff(String): Plane+getArrivals():PlaneEnumeration+getDepartures:PlaneEnumeration-nextFreeRunway(): RunwaynextFreeRunWay() : Runway

PlaneList

-planes: Hashtable-circlingQ: Vector

+PlaneList()+register (String, String)+circle (String)+descend(String, Runway)+land(String, int)+boarding(String, String)+leave (String)+listArrivals(): PlaneEnumeration+listDepartures(): PlaneEnumeration+isInList(String):boolean+getPlane(String): Plane+getRunwayNumber() -nextToLand():Plane

Runway

-number: int-allocated: boolean

+Runway(int)+getNumber():int+isAllocated():boolean+book()+vacate()

Plane

-flightNumber: String

-cityOfOrigin: String-status: int-theRunway: Runway

+Plane(String, String)+getFlightNumber():String+getCity():String+getStatus():int+getRunway():Runway+getRunwayNumber(): int+isAllocatedARunway():boolean+allocateRunway(Runway)+vacateRunway()+upgradeStatus()+changeCity(String)

0..1

permitted to land on

*4

updates

1

0..1

1

Detailed design for the airport application

Composition in UML

When an object from one class contains a fixed number of objects from another class, this special kind of association is called a composition

Airport

Runway

4

The UML notation for composition is the same as that for aggregation, except that the diamond is filled rather than hollow

Implementation

It makes sense to bundle these classes together into a single package (airportSys).

This means that all our classes will begin with the following package statement:

package airportSys;

It is a good idea to hide implementation level exceptions so define a general AirportException class.

Outline of this and all other classes can be found in Charatan and Kans Chapter 20 section 20.5.

Testing the airport application

A useful technique to devise test cases during integration testing is to review the behaviour specifications of use cases, derived during requirements analysis.

Often, there are several routes through a single use case.

Different routes through a single use case are known as different scenarios.

During integration you should take the place of the user and make sure that you test each scenario for each use case - this is often known as scenario testing

"Record flight’s request to land" use case:

“An air traffic controller records an incoming flight entering airport airspace, and requesting to land at the airport, by submitting its flight number.

As long as the plane has previously registered with the airport, the air traffic controller is given an unoccupied runway number on which the plane will have permission to land.

If all runways are occupied however, this permission is denied and the air traffic controller is informed to instruct the plane to circle the airport.

If the plane has not previously registered with the airport an error is signalled.”

Identifying scenarios

Scenario 1An air traffic controller records an incoming entering airport airspace, and requesting to land at the airport, by submitting its flight number, and is given an unoccupied runway number on which the plane will have permission to land.

Scenario 2An air traffic controller records an incoming entering airport airspace, and requesting to land at the airport, by submitting its flight number. The air traffic controller is informed to instruct the plane to circle the airport as all runways are occupied.

Scenario 3An air traffic controller records an incoming entering airport airspace, and requesting to land at the airport, by submitting its flight number. An error is signalled as the plane has not previously registered with the airport

Current state of system

DEPARTURESFLIGHT TO RUNWAYBA123 London 1TK999 Tokyo 2

ARRIVALSFLIGHT FROM STATUS RUNWAY

LF016 Moscow Landed 3SP001 Madrid Not yet arrivedUS642 Florida Not yet arrived

Testing Scenario 1

The first scenario should be the simple case of an arriving plane being told to land on a particular runway.

So far, runways 1, 2 and 3 are occupied but runway 4 is unoccupied.

If either flight SP001 or US642 arrives at the airport now, it should be told to land at the airport.

Enter flight number: SP001Land on runway 4

As expected this plane is asked to come in and land on runway 4.

All runways are now occupied so we are in a position to test the second scenario of the "Record flight’s request to land" use case.

In this scenario, the arriving flight should be told to circle the airport.

Testing Scenario 2

Enter flight number: US642No runway available, circle the airport

The registered flight US642 arrives at the airport and is correctly told to circle the airport.

In this scenario, a flight arrives at the airport without first registering; this should raise an error.

Testing Scenario 3

Enter flight number: CK001AirportException: this flight has not yet registered at PlaneList.getPlane(Compiled Code) at PlaneList.circle(PlaneList.java:32) at Airport.arriveAtAirport(Compiled Code) at RunAirport.option2(Compiled Code) at RunAirport.main(RunAirport.java:30)

Here, flight CK001 has not previously registered with the airport; so an error is correctly flagged followed by a stack trace of the exception.

The stack trace

A stack trace lists the original method that generated the exception object (along with its associated class), then methods that received that exception object are listed.

This trace can then help pinpoint errors quickly during the testing phase.

The stack trace is obtained (and printed to the console) by calling a printStackTrace method as follows:

catch (AirportException e){ e.printStackTrace();}