Case Study part 1: from UML to Java IM103 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 flights 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 number allocated book() vacate() isAllocated() Plane flightNumber cityOfOrigin status upgradeStatus() 0..1 permitted to land on

Runway number: int allocated: boolean book() vacate() isAllocated(): boolean Plane flightNumber: String cityOfOrigin: String status: int theRunway:Runway upgradeStatus() 0..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(): Runway nextFreeRunWay() : 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 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 flights 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 1 An 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 2 An 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 3 An 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 DEPARTURES FLIGHTTO RUNWAY BA123 London 1 TK999 Tokyo 2 ARRIVALS FLIGHTFROM STATUS RUNWAY LF016Moscow Landed 3 SP001 Madrid Not yet arrived US642 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: SP001 Land 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 flights request to land" use case. In this scenario, the arriving flight should be told to circle the airport. Testing Scenario 2 Enter flight number: US642 No 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: CK001 AirportException: 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(); }