Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Sp2002 Midterm Review: Hotel Doors OOA/D
Back to Spring 2002 Midterm Review
Key, KeyCode, KeyReader, DoorLock, DoorCode, CentralDatabase
Each key would have a KeyCode.
Each door would have a KeyReader, a DoorLock (the deadbolt) and a DoorCode (stored in the CentralDatabase).
Customers receive a key and a room when registering at the hotel. The central database matches the KeyCode of the Key to the DoorCode of that room.
When a key is inserted into the KeyReader, the KeyCode is sent to the CentralDatabase. If it's the master code, any door opens. Otherwise, it checks if the KeyCode opens that DoorCode. If so, the DoorLock opens.
If a customer looses the key or checks out, the CentralDatabase changes the DoorCode.
1. Definately need Key and DoorLock classes. I would consider a NewKey class for keys that would replace lost keys, but ultimately this wouldn't work. A new key become and normal key immediately, it cannot remain new forever. Also, I would consider having a Customer class, but I would reject this. A customer is outside the scope of the system, as it does not matter who is carrying the keys or how they get into the doors.
I agree with the choice of the classes - Key and DoorLock. The Key would know it's number and collaborate with no other class. The DoorLock class would know the numbers of the keys that it would validate. So it would have to collaborate with the key class to get its encoded number.
I have two questions about this.
1) One that the Key class merely becomes a storage class but there seems to be no way around this.
2) It seems from the statement of the problem that the customer affects the system directly since everytime a customer checks out - and this is assuming that every customer will ultimately check out, the DoorLock would have to be re-programmed to understand different encoded numbers on the new keys, which would be updated in the database.
The problem says you're designing a door lock and tracking system. But after that, not much is said about how the customers are tracked. By the wording I would assume that there are some other classes designed to keep track of the registry. This system would probably communicate with the key and lock databases to update them when people check out. So maybe the customers only interact with the registry system and are issued cards as needed. They don't need to know anything about how the key and lock system is being handled.
Looks like you need LockDatabase class too. Someone to own all the DoorLocks, all the current Keys, and have some way to map them on to each other. It should also be able to update a DoorLock to accept a new Key. It might have to hold all the old Keys as well, so that new Keys can not be created that have the same numbers as an old Key. DoorLock is going to need to accept at least two Keys at a time, the Key to which it was assigned, and the master key. MasterKey is a rejected class (subclass of Key) because it adds no functionality to Key. In fact, isMaster doesn't even need to be an attribute of Key, because the master key is just a normal Key that, oddly enough, all DoorLocks respond to.
Michael L. Mitchell
Another possibility here would be to have a Lock class that can be opened by the master key and have it subclass to a DoorLock class that has its own current key value. I don't think it's really necessary to have a Key class because you are only dealing with the locks here, and the locks know their key value. You would still need some kind of LockDatabase class though, to handle resetting the doorlocks with new key values.
Link to this Page