Professional Documents
Culture Documents
Spring 2010
SimWarehouse
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) (2, 0) (1, 0) (0, 0) (3, 1) (2, 1) (1, 1) (0, 1) (3, 2) (2, 2) (1, 2) (0, 2) (3, 3) (2, 3) (1, 3) (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.
Spring 2010
Methods:
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.