Вы находитесь на странице: 1из 2

CS 3114 Data Structures & Algorithms

Spring 2010

SimWarehouse

Design, Association, Aggregation and Responsibilities

Consider the internal operation of a large warehouse. The warehouse floor is a rectangular grid of identical cells, each large enough to hold a number of units. (For our purpose, we don't care what the product is; we'll just assume that the warehouse stores a bunch of units that are all logically identical.) The primary job in the warehouse is moving units from one cell to another (or perhaps from to a warehouse entrance). The warehouse manager assigns jobs to a forklift, which then carries out those jobs in the order they were received.

The simulation of this system is time-driven. That is, the simulator will include the ability to simulate "ticks" of a clock. Whenever a tick occurs, some objects in the system are notified of that, so that those objects can update their state.

The warehouse cells form a rectangular grid, like a chessboard, and the cells are identified by row and column indices, with coordinate (0, 0) at the southwest corner:

(3, 0)

(3, 1)

(3, 2)

(3, 3)

(2, 0)

(2, 1)

(2, 2)

(2, 3)

(1, 0)

(1, 1)

(1, 2)

(1, 3)

(0, 0)

(0, 1)

(0, 2)

(0, 3)

Jobs take the logical form "move N units from cell (a, b) to cell (c, d)". When starting a job, the forklift must first move from its current location to the cell where it will obtain the units, then obtain those units, and then move to the cell where it will deposit the units, and deposit them there. There is always enough free space within each cell for the forklift to move through it, so there are no barriers to be navigated around (aside from the outer wall of the warehouse). For the sake of predictability, the forklift uses the following protocol when moving to a cell: first move into the correct row and then move to the correct column.

Warehouse cells can only store a limited number of units, and the forklift can only carry a limited number of units at once. Given those limits, some logical issues arise. What if the forklift, while attempting to obtain units, finds that the cell it was directed to does not contain enough? What if the analogous difficulty occurs when the forklift is trying to deposit units? What if the forklift is told to move more units than it can carry? All of those questions must be given satisfactory answers; for now, it is enough to note that the simulation must detect and handle them.

Units are identical, but each one does have a unique identifier. That identifier doesn't really matter to the warehouse manager or the forklift, at least as far as decision making is concerned. However, when jobs are carried out it is useful to keep track of which units are actually affected. When a unit is created (enters the warehouse from outside, if you like), it is assigned a tracking number. Units are assigned number sequentially, starting at 1, in order of creation. No tracking number will ever be used for two different units, even if a unit is destroyed or removed from the simulation.

It must also be possible to locate specific units within the warehouse according to their tracking number; in other words, you will be given an order, which will include a list of specific tracking numbers and you will need to be able to efficiently determine the coordinates at which that unit is currently located.

Before you can do much implementation, many details must be specified. However, the description above is sufficient to do quite a bit of design work, and even begin implementation of some of the necessary classes.

While doing this, be sure that you give careful consideration to the following questions:

What classes are needed for the simulation, including operational control if this is script-driven?

What relationships exist among those classes? In particular, where are there knows-a relationships, and where are there has-a relationships?

What responsibilities should each class have? Pay attention to how the actions within the system are described.

CS 3114 Data Structures & Algorithms

Spring 2010

Design Homework Problem:

You will produce an interim design, which you will submit as an extra-credit assignment, weighted 2.5%.

You should identify a reasonable set of classes, document each of those classes with a class form, and explain how you will use association and/or aggregation in the program. There is no specified minimum number of classes; however, it is better to have too many than to have too few. Your design should largely isolate file accesses (input/output) from computation. You should, of course, attempt to identify classes that correspond to useful clear abstractions, provide public interfaces that are both useful and coherent, and achieve a reasonable balance of responsibilities among the classes.

You are free to use Java library classes as you see fit. There are no complex data structures issues in this system, and you may choose to use any structures you think are appropriate.

The class forms should follow the template given below:

Class name:

The name should be descriptive.

Purpose:

Give a one or two sentence description of the role the class plays in the system.

Data members:

For each data member, list a descriptive name, indicate the expected data type, and give a clear one-sentence description of its purpose. If the data member is an object of a class, indicate whether the relationship is one of aggregation or association.

Methods:

For each method, give a descriptive name, and a clear, one sentence description of what the method does.

You must also produce a diagram illustrating what communications take place between the classes/objects that will make up the system. For each such communication, you must indicate the classes involved, the direction of the communication, and give a brief but informative description of the nature of the communication.

Your design will be evaluated, and a discussion of reasonable design alternatives will be held in class or posted on the course website. Submit your design either as a plain text file or a typed MS Word document. Submissions made in other formats, such as PDF or scanned handwritten work, will not be graded.