Reference no: EM131421052

TASK 1 : Read The definition of the Item interface and implement TrainCar

Your are being provided with
1. Item.java
2. Automobile.java
3. Ford.java
4. javadoc of TrainCar.java

You will not need to change or turn in Item, Automobile, or Ford. You cannot? redefine Item.java. It is a formal interface definition and that is the interface for which we will test your homework. Automobile and Ford are classes that implement the Item interface. You should be able to answer the following questions about this code

- given these definitions, is the statement new Automobile() allowed in any java file?

- Does Ford.java implement the Item interface? That is, is the statement Item it = new Ford("mustang"); legal?

- How is the constructor of Automobile invoked in Ford.java?

- Why do you think that the method model2weight in Ford.java needs be declared as a class method?

Implementing TrainCar

TrainCar implements some straightforward methods. Its job is to store references to objects of type Item. Since Item is an interface, this means store objects that implement the Item interface.

- A TrainCar has a maximum weight.
- It has a method, canLoad() that returns a boolean to say if an item can be loaded
- Is has a method, load(), that adds an item to the "contents" of the TrainCar. load() should check the result of canLoad() before loading.
- Items are stored sequentially (in an internal array or ArrayList). The first item loaded is index 0, second is index 1, etc.
- getContents() returns an array of Items that have been successfully loaded. It returns in the order in which they were loaded.
- getWeight() returns the sum of the weights of all the Items it contains
- See the TrainCar.pdf for the javadoc generated from our implementation.

You are being provided javadoc for TrainCar, but no starter code. We expect your version of TrainCar to reasonably reproduce the javadoc, that means that you have to write your own javadoc comments in your version of TrainCar.java. We are not concerned about character-by-character reproduction ?of your javadoc comments when compared to the supplied javadoc webpage. However,

1. All methods and constructors must be documented in the javadoc style

2. % javadoc TrainCar.java should produce no errors or warnings about missing documentation.

Other requirements of TrainCar:

1. Implement all of the public methods
2. Define no other public methods, constructors, or fields
3. You may use ArrayList or the Arrays class internally to your implementation, but that is not required. The assignment is easily done with standard arrays.
4. you may add any number of private variables or methods
5. To compile TrainCar, only Item.class should need to already be compiled.

A strategy for developing and testing TrainCar

You should create a small program that creates a TrainCar instance, some instances of Ford and then loads the TrainCar with your Automobile (Ford) instances. Finally it should print out the item descriptions. We are not grading this and you are not handing in the small program. It's up to you to figure out what you want to test to verify that your TrainCar methods are working properly. You shouldn't skip this step, or other parts of the assignment will take longer. Your small program will allow you to become familiar with the Item interface. Don't forget to test edge conditions, like trying to load more into already full car, or trying to load into a car with no cargo capacity.

In order to get started with the file TrainCar.java, you should make sure to write a working "stub" for each method in the javadoc. That is, write a method that returns some (probably incorrect) value that matches the return type, like -1 for an int, or null for an array. This will make sure you have a class definition that can compile with the other pieces of the project sooner rather than later.

Task 2 - Create an Electronics class that Implements Item

You are to create an Electronics class that implements Item. The constructor should have the following signature:

public Electronics (String description, double weight)

You should override the toString() method of Object so that the string returned has the following format:

"Electronics: <description> (<weight> KG)"

Where <description> and <weight> are the String description passed in the constructor and <weight> is the weight passed into the constructor. Example toString Output:

"Electronics: SystemZ-Desktop (6.2 KG)" would the String return with the following statement new Electronics("SystemZ-Desktop", 6.2).toString()

There are no other requirements of the Electronics class. Suggested testing of Electronics modify your small test program above and add the creation of some number of Electronics objects and add them to the TrainCar instance. (TrainCar itself should need NO modification to accommodate Electronics, why?) You should only need to modify a few lines of code of your test program to construct a TrainCar instance that now has Fords and Electronics packed.

You will turn in Electronics.java.

It should be documented with javadoc, implement the Item interface, and provide the appropriate constructor and toString() method. There are no other requirements of Electronics. java (the class be will short, 15-20 lines total).

Task 3: Train.java and TrainMain.java

We are providing you with a starter Train.java. It has been documented using javadoc comments and you should look at these and (if it helps you) generate the doc for reference.

We are also providing FrontLoader.java and Loader.java. FrontLoader.java is simple Loader algorithm. You should develop Train.java in steps. It's important to reason about how the Loader is being used, how to add TrainCars to the Train instance, how to return the various Item [] and Item [][] arrays being asked for, computing total weight of the train, and the like.

TrainMain.java is testing program that requires Train, TrainCar, one or more classes the implement Loader, one or more classes that implement Item. It is pretty complete, but you need to read it. Like PR#2 you will turnin in some testing scenarios that use the commands defined in TrainMain.java. There are several lines marked FIXME in TrainMain.java -- these indicate places where, once you implement some other piece, you can remove the comments and enable some new functionality. For example, when you implement the Electronics class, you can then use the code in the electronics command to construct and load those items. The same goes for the different loaders.

TrainMain has several commands you can use; a few examples are in testinput1.txt:
- manifest -- Prints out the number of cars, total train weight, and a summary for each car containing the number of items and total weight (using the methods you implement to get this information, so if you haven't implemented one of the appropriate methods, the
wrong information will print)
- manifest n -- Prints out all the items in the car at index n
- add-cars n w -- Adds n cars each with weight capacity w to the train
- electronics desc w n -- Attempts to load n electronics items, each with weight w and description desc (you can enable this once you implement Electronics)
- ford model n -- Attempts to load n Fords of the given model onto the train, each with the given model

When TrainMain starts up, it prompts the user which of the four loaders they'd like to use.

One of the given loader type is instantiated, and the Train constructor is called with the given loader. Initially, only FrontLoader is available; you can enable the other three as you implement them (see below for more on loaders).

We suggest the following order of development
- Put in default values for the return of each existing method
- Implement/Debug the Train Constructor
- Implement/Debug addCars (test by just adding a single car)
- create and add some items to the Train (since it is a single car at stage is should behave just like adding items in Task 1).
- Implement/Debug the getContents(int car) method
- Implement/Debug the getWeight(int car) method
- Add multiple cars to the train.
- Create and add items to the Train. add enough items that the FrontLoader will have to eventually choose to load items into the second and third car.
- Verify that getContents/getWeight work for all cars
- Implement/Debug getWeight() - weight of all cargo
- Implement/Debug getContents() - All contents, car by car.
Note that all of this testing is being done with just a single Loader algorithm, the FrontLoader. You should be able to manually verify the output.

Task 4: Develop three more Classes that implement Loader

There are three more classes that you are to define to implement different loaders
They are
- RearLoader.java
- RoundRobinLoader.java
- FairLoader.java
Since these are just "strategies" for which car to choose when loading, they each have different goals. Note that Train.java, TrainCar.java, Item.java, Ford.java,

Automobile.java. Electronics.java do not have to change at all as you create new classes that implement Loader. In our setup only TrainMain.java needs to know how to create a specific Loader and then instantiate a Train with that loader. Please re-read this paragraph, understanding why this works (via runtime polymorphism) is key to gaining insight into a key feature of any object-oriented language.

The following gives rules/examples of how each Loader strategy fills a train. For this example:

Train has 5 cars, Cars have the following weight Capacities:
0: 10 KG
1: 8 KG
2: 6 KG
3: 4 KG
4: 3 KG

We will load Items A-Z, in that order. All items are 3KG in weight. The train has a maximum capacity of 31 KG.

RearLoader -- Loads from rear of the Train first

Loading A - Z (we cannot load all), the train will loaded as follows. This the output from a simple test program that loads electronics classes into a train with cargo capacities above
=== Train Weighs 27.000000 KG ===
==== CAR 0 (9.000000 KG) ====
Electronics: G (3.000000 KG)
Electronics: H (3.000000 KG)
Electronics: I (3.000000 KG)
==== CAR 1 (6.000000 KG) ====
Electronics: E (3.000000 KG)
Electronics: F (3.000000 KG)
==== CAR 2 (6.000000 KG) ====
Electronics: C (3.000000 KG)
Electronics: D (3.000000 KG)
==== CAR 3 (3.000000 KG) ====
Electronics: B (3.000000 KG)
==== CAR 4 (3.000000 KG) ====
Electronics: A (3.000000 KG)
RoundRobinLoader ?-- Starting from the front it loads the first item in car 0, next item in car 1, ... when it gets to car 4, the next car loaded is 0. If there is no capacity in the car that should be next, it keeps trying in round-robin fashion until it exhausts all possibilities.

The RoundRobinLoader must remember the last car it selected for chooseCar. Below is output of one of our simple test programs that is loading electronics using the RoundRobinLoader

== Train Weighs 27.000000 KG ===
==== CAR 0 (9.000000 KG) ====
Electronics: A (3.000000 KG)
Electronics: F (3.000000 KG)
Electronics: I (3.000000 KG)
==== CAR 1 (6.000000 KG) ====
Electronics: B (3.000000 KG)
Electronics: G (3.000000 KG)
==== CAR 2 (6.000000 KG) ====
Electronics: C (3.000000 KG)
Electronics: H (3.000000 KG)
==== CAR 3 (3.000000 KG) ====
Electronics: D (3.000000 KG)
==== CAR 4 (3.000000 KG) ====
Electronics: E (3.000000 KG)

FairLoader - ?Each time chooseCar is invoked, FairLoader starts at the front of the train (car 0) and finds the first least-loaded car in which the cargo will also fit. In the example A-Z and cars, FairLoader will give the identical results as RoundRobinLoader. However, that is not always True. Suppose we now load a sequence of items:

A, A1, B, B1, C, C1, D, D1, E, E1, F, F1,....

Where the "1" versions of the items are 1KG, but we have the same Car capacity as before. In our test program that generated the following output, it stopped adding items the first time it encountered an item that would not fit in any car.