Use the name of "mp3" to submit the project using turnin.
You may work on this project by yourself or with one other feloow student currently taking CS 441.
You can get 10 pts extra credit by displaying information using a GUI interface instead of a text user interface for the zone clients and the inventory manager clients. If you create a GUI interface for the server (the Primary controller) you can earn another 5 pts extra credit. We leave this to you to determine what you might want the server to display.
For example, assume we were simulating the warehouse for Amazon.com. Amazon sells books, software, music CD's, movie videos, etc. We assume that their warehouse is divided into sections (or zones). At one zone all of the books are kept. At another zone all of the sofware is kept. If I place an order from Amazon that has a book, a PC game and a movie on it, a tote will move to the book zone, then to the software zone and finally to the movie video zone. At each zone, the specific item ordered will be removed from a shelf and placed in the tote. Since the order does not have any music CD's on it, the tote should not visit the "music zone".
For the assignment, we will create a server that we will call the primary controller. This will be the "main brain" that will move the totes around the warehouse. The PC needs to kept track of the totes and which zones a tote must visit. The PC will have two types of clients: a zone client and an inventory manager client.
The zone client is nothing more that a glorified microprocessor. We assume each tote has a unique number which is posted on the side of it with a barcode label. An actual zone client would consist of a barcode scanner to read the tote number and pneumatic arm that diverts the tote into that zone if that tote needs to visit that zone. For our simulation, we won't have a scanner or a pneumatic arm. We will create a java process in which a user will type in a tote number and output a "yes" or "no" message if that tote should visit the zone the process represents. When this java process begins, it should connect to the Primary Controller via a socket. Somehow the "zone client" must inform the PC what zone it is simulating. I leave this up to you to determine how this should be done. So when a number is entered at the zone client, that number is transfered to the primary controller and the primary controller will respond to inform the zone client if that tote should be diverted to visit that zone. If an unkown tote number is given to the primary controller, the primary controller should respond with a "no divert" message. For the simulation, the zone client will need some form of user interface. This can be either text based or GUI (Graphic User Interface) based. It should allow for the input of a tote number and be able to display some user friendly message whether the tot with that number should be diverted or not.
The inventory manager client will be the main place where information is entered and displayed for our simulation. While the user iterface could be either text based or GUI based, a GUI based interface is preferred (the point values will be the same but a GUI interface will be easier to get points for "user friendliness"). The inventory management client will send information to the primary controller about which zones a tote is to visit. Thus a message from the inventory manager to the primary controller needs to contain a tote number and all zones that tote will visit. As the tote "reaches" each of the zones (i.e. a user enters in that tote number at one of the zones), the divert message is to be generated based on the information sent by the inventory manager. When a "yes divert" message is sent by the primary controller to a zone client, the primary controller must also send a message to the inventory manager to inform it that the tote reached that particular zone. The system must allow for multiple inventory managers.
The user interface for each inventory manager must allow for input of tote numbers and the zones to visit (this will activate the tote number). The user interface must somehow display the list of "active totes" and "completed totes". An "active tote" is a tote that has not as yet visited all of its indicated zones. When this information is displayed, there must be a way to see which zone are yet to be visited. A "completed tote" is a tote that has visited all of its indicated zones. The user interface must also have some real-time display that will show when a tote visits a zone.
Once a tote number is activated, that number cannot be "reactivated" until the original activation is completed (the tote has visited all of the zones specified in the original activation). If such a thing is attempted, an error message should be generated. Note when multiple inventory managers are connected to the primary controller, they are to share the tote numbers. So it is an error if one inventory manager attempts to activate a tote number that is active on another inventory manager. Also note that information displayed for the active totes, the complete totes, and the real time display must only show information about totes that were activated on that inventory manager. It is left up to you what to do if an unknown zone is entered for a tote. It is suggested to give a warning message and ignore any unknown zones.
The user interface for the primary controller is left up to the user, since no information is entered at the primary controller by the user. However, the primary controller should display some messages reflecting what is occurring on the system (for debugging purposes if not used for any other reason). Perhaps you may want to add some way to shut down the primary controller, but again that is left up to you.
The primary controller will need to maintain information about all active totes on the system, since we don't want to clog up our network with additional traffic from a zone to the primary controller and from the primary controller to an inventory manager everytime a tote reaches a zone. Once a tote has visited all specified zones, the primary controller can "forget" all about that tote. How you use the sockets is left mostly up to you. Since there are two types of clients, you might want (or you might not want) the primary controller to listen on two different ports. The protocols and messages sent via the sockets is also left up to you.
Note that with this simulation, it may be possible to create some scenerios that could/would never occur with a real warehouse conveyor system. If you think you have encountered such a scenerio during your development of this project, have your simulation do "something reasonable". Note you may need to justify to the professor or TA why what you did is reasonable.
Your program is to be submitted electronically via the turnin command on the CS Department's LINUX machines. The project name for this is mp3. All programs are expected to be written in good programming style using the java programming language.
How to turn in your work
Turnin your program electronically using the "turnin" command from your CS account as follows:
turnin -c cs441 -p mp3 [your project directory]
where the [your project directory] is the directory name under which you have
all your files related to this programming problem. The turnin command will
automatically compress the data under your directory, so there is no need to do
the compression by yourself.
Notice you can only invoke turnin command on the Linux machines in the lab or after logging into the server machine oscar.cs.uic.edu.
If you want to verify that your project was turned in, look in the turnin
directory for a file with your userid. For instance for this project, from your
CS account you would type:
turnin -c cs441 -p mp3 -v
Note that you can execute turnin as many times as you would like, up until the program deadline when turnin will be disabled for this project. Each time you execute turnin for a project, you overwrite all of what you had turned in previously for that project.It does not work in an incremental way.