Lab 8

Last modified: November 11 2008 11:24:38 AM

Introduction.

In this lab, you will be leveraging the power of polymorphism as well as using a design pattern to simulate what happens when people arrive and leave an airport.

---

Objectives

We will concentrate on the following idea that was discussed in class:

• Inheritance
• Polymorphism
• Method overriding

There will also be a review of the following two concepts previously covered:

• ActionListeners
• Drawing graphics to the screen
• Programs that react to user actions
• Defining classes
• Graphical components from javax.swing package
• Creating objects
• Calling methods
• References

---

Lab Tasks

Eclipse Project Setup

Check out the Lab 8 Skeleton from the repository. It is called AirportSimulation. Note that for this assignment, there is a large amount of source code included in the package airportsimulator. You should not modify this code in any way. Rather, you should write your code in the package named lab8. You are encouraged to look at the airport simulator code, but you should not modify it.

Attendance

Attendance will be taken for this lab and will count towards part of this lab's grade.

Design

You will need to design your solution using UML before you begin coding. You will also be required to submit a UML diagram named Lab8.grn with your final submission.

---

Assignment Description

General Description of Assignment

In an airport, there always seem to be planes landing and people leaving the airport in cars, shuttles, and buses. This simulation will show this process. The user is in charge of when and what type of planes land as well as what type of vehicles arrive to pick up newly-landed passengers. Some of this project has already been implemented for you. Your job in this assignment is to make vehicles that appropriately drop off passengers and pick up passengers when the user of your program asks for them.

The simulation is ultimately controlled by a timer which the user can also start and stop to start and stop the simulation. This is part of the functionality that has been provided for you. Also, the management of the people waiting has been implemented as well as a good deal of the graphics. You will focus on what the vehicles need to do and create the vehicles for this simulation.

There is a good deal of code in the package airportsimulator, the Javadocs for which are located here. You are free to look at the library code as much or as little as you'd like. However, there may very well be things in the code we simply haven't covered in class yet, or won't be covered in this course at all. You must not modify the library code in any way. Therefore, it is suggested that you begin by looking at the Javadocs for help on the project. When you have the project completed, feel free to look at the functionality of the simulator if you are interested.

Start to fill in the code

The first thing you should do is look at the code in the lab8 package. There is a file called App that has a main method. In order to get this program up and running, you should create an instance of a airportsimulator.Window, but in order to do this, you need something whose type is IBehaviorSelector to pass in as a parameter to the Window's constructor. That means, you will need to create a class that implements that interface. But, you don't know how to implement the methods at this point, which is fine. You should simply leave them with empty method bodies. Now you can create the window, pass in the appropriate parameter and run the program. You will see what has already been built for you.

Note that all of the graphical components are already there - the buttons, the drawing canvas, everything. You will be fitting your code into this framework. This is what the interface was for. When the buttons are clicked, they call corresponding methods from the interface. You need to fill in those methods so that they do what they are supposed to do when the user clicks on the buttons.

Make the Buttons Do Something

Fill in one of the methods so that it creates an instance of an airportsimulator.Vehicle whenever it is clicked. This is the first step in getting the simulation up and running. Note that this is not as simple as it first seems. The Vehicle requires a window so that it knows where it should be drawn upon, but you create the Vehicle in your class that implements the interface, not in the window. You need to make sure that your class that implements the IBehaviorSelector interface can talk to the Window object. This will involve an instance variable and a mutator method, which is a variation on how to code the association relationship. Then, when you click on the appropriate button, you will see a vehicle appear on the screen. You can start the simulation by clicking on the Start Simulation button, although at this point, it won't appear to do anything.

Make Your Vehicle

You should not use the airportsimulator.Vehicle directly, but instead should create a subclass for it. Create a subclass now. Switch your code from above to create an instance of one of these as opposed to the airportsimulator.Vehicle. The behavior should not change.

However, we want it to change slightly to fit the specifications of this assignment. Instead of the vehicle appearing anywhere on the screen, we want the arriving land vehicles to appear on the left and the air vehicles on the right. This behavior is controlled by the Simulator object. We can retrieve a Simulator from a Window and then place the vehicle into the appropriate queues. Do this now so that your vehicle appears in the appropriate sides of the screen depending on which method you are implementing.

Make the Other Vehicles

Now make the rest of the land or air vehicles, whichever ones you didn't make previously and test out all your buttons to make sure that all the buttons make a vehicle appear. Vehicles appear in random colors for now, so you won't really know what type of vehicle you are producing, but clicking on each button should make one more vehicle appear on the screen. We'll work on differentiating between different types of vehicles next.

Give Vehicles Behavior

In order for your vehicles to react appropriately to pick up or drop off passengers, we need to modify the behavior of the vehicles for each time the simulation timer goes off. When the timer goes off, and they get told to execute their behavior, we need to make sure our vehicles respond appropriately. First, let us differentiate between the different types of vehicles based on color. For each one of the vehicles created, pick a different color and make sure when that vehicle is created, it appears in the appropriate color.

Now, we need to implement some Design Patterns

Design Patterns

Design patterns are particular arrangements of classes which lead to flexible, robust and extensible software. You can read our short descriptions of what the patterns do, and for the purposes of this lab that should do. But if you're a bit curious, you can find out more by reading a good general description of patterns, one of which can be found online here. In particular, look at the following pattern descriptions:

• Strategy
• Null Object

Strategy

The purpose of the strategy pattern is to allow the behavior of an object to change according to the "strategy" chosen. A strategy is an "objectified" method, i.e. a method which is wrapped up in an object. In the strategy pattern an interface specifies what method (or methods) each strategy implementation must provide. There can be many implementations of a given strategy pattern interface. In this lab the behavior classes are strategies, which implement the interface for a behavior that you write. Below is a UML that gives information about the general pattern.

Null Object

The purpose of the null object pattern is to model something which does nothing. This may sound odd, but it is an incredibly useful idea. A null object is instantiated from a class which implements a given interface by "stubbing out" all its methods. To "stub out" a method means to define a method with an empty body (in the case of a void method) or to define a non-void method to simply return null.

Let's implement these patterns

First, you need to create an interface for your Behavior and then you will create many different behavior classes that implement this interface. Your Behavior interface should have one method named execute in it. This method will need to take in a parameter of type airportsimulator.Simulator because when we execute the behavior we will need to tell the simulator what we want to do with people (drop some off or pick some up).

Create one class that implements this interface and call it NullBehavior. Do not place anything in the method body of execute.

Modify your Vehicle class so that it has a behavior. The declared type of the instance variable will be your interface type. The actual type will be NullBehavior.

Now, all the vehicles you create will have a null behavior. To see that this is the case, you can make the null behavior do something (like print out text to the console). This defeats the purpose of the null behavior, but it will show us that the vehicles and behaviors are working properly. Put this line into the execute method of NullBehavior

System.out.println("Doing nothing.");

Now when you run it, you should see that line. If you don't, then you haven't appropriately overriden the update method from the airportsimulator.Vehicle. You need to make sure that your subclass overrides this method. Once you do that, your message will appear.

Now, create a class for the Helicopter's behavior. Helicopters are generally small and can only hold a few passengers (think 1 or 2). Therefore, when a helicopter arrives, it will tell the simulator that it is adding that many passengers. Try this out and notice the passengers appearing in the passenger waiting area.

Now create a behavior for picking up passengers. Test out to make sure that the passengers are coming and going as you'd expect. Remember that you can stop the simulation at any time to make sure you know what is happening.

Complete the assignment by creating the rest of the behaviors.

---

Due dates

Note that Lab 8 and Lab 9 are due to be turned in on the same day. However, Lab 8 will be discussed during the week of 11/3 in recitation, and Lab 9 will be discussed during the weeks of 11/10 and 11/17. Therefore, the assumption is that you have completed Lab 8 (or at least a significant amount of the functionality of Lab 8) in 1 week and then will be prepared to work on Lab 9 starting the next week. This is not an invitation to wait until the last minute to start work on both assignments because it is guaranteed that you will not finish them if you wait to begin.

The Lab8.jar must be submitted using the electronic submission command by the end of the day Sunday, November 23rd (11:59:59pm). Note that your submission must include your Java source code files as well as a file that contains your UML diagram.

---