< Day Day Up > |
Sam and I need to determine how to phase the new computer system into production. Often systems under development can be run in parallel with older systems. When a new system produces exactly the same results that the old system does, the old system is retired during a quiescent period, such as when the business is closed. We will take this approach with Sam's system. 7.3.1. Loading Current DataFor Sam's system, we need a way to get the current data into the system. That data includes the discs in the inventory, the customers, and the current rental data. I met Sam for coffee. Sam is a coffee connoisseur. He can spout off the differences between beans from each country and each growing region. I can barely differentiate between regular and decaf. He ordered a grande . I wanted a large coffee (it might be a long discussion). When I ordered a supersize cup, the clerk looked at me quizzically. "Sam, I've been thinking about how we're going to start up the system," I stated. "I've been wondering about that also," Sam said. "Since everything is currently on paper, you'll need to convert the information to digital form. I can specify a format that the information can be converted into so that it can be read into the system," I suggested. "I'll take a look around for services that can scan in my current index cards to create these files," he offered . "It will be hard to capture the current rentals. It will take time to scan the index cards. By the time they're done, the rentals will no longer be current," I said. I told him we definitely need to create a machine-readable form of the data to initialize the values of Customer s and CDDisc s. Since CDDisc s refer to CDRelease s, we need to have data to initialize those objects as well. For these three classes, we add an additional method to their responsibilities: [*]
CustomerCollection add_customers_from_file(String filename) CDDiscCollection add_cd_discs_from_file(String filename) CDReleaseCollection add_cd_releases_from_file(String filename) Each method reads a file and creates objects initialized from the data in the file. At some later point, we will determine the best way to represent the data in these files. The format could be tab delimited, XML, or some other form. Tim and I realize that these methods will also be helpful in testing the system. Test records can be kept in text files and read in to initialize the system. We get two uses for methods: migration and testing. Since it is hard to capture the current rentals, Sam and I create a process for obtaining that information. As each CDDisc is rented, the information is recorded both on the current card and in the new system. After a few days, a printout of the current inventory of what is rented and not rented is checked against the actual physical inventory. This comparison helps us confirm that all the information was captured correctly in the conversion process. The need for a current inventory printout in migration points out a feature that Sam had missed in his original specification for the system. The inventory printout is a needed feature for periodic inventory audits . For CDDiscCollection , we add an additional responsibility: creating a DTO that contains the current inventory. The DTO includes every CDDisc that is in the collection with its PhysicalID , the CDRelease title, and the rental information, if currently rented. The DTO can be sorted by PhysicalID or by whether the CDDisc is rented or not, or both.
7.3.2. Anticipating Potential ProblemsA complete inventory is the only way that Sam can be assured that his rental data is captured correctly. Whenever receiving data that has been created elsewhere, you need to be concerned with the correctness of the data. Even if the data is coming from an existing computer system, you might still need to be concerned with data correctness. The data on the previous system might not have been validated . If the data required translation, the translation might not have been performed correctly. For example, suppose that we were migrating from a previous computer system. and that the previous system did not have a variable that represented the state of a rental. The initial value in the new system will have to be determined from some combination of other values in the previous system. That process of determination might not have been correct. When the conversion occurs for Sam's system, a number of possible errors can arise. We might not deal with them all at this time, but at least we should examine them to see the possible system ramifications . When we check the CDDisc inventory versus the real physical inventory, there are a number of possibilities:
These errors might be due to errors in the input data or errors in the program. We need to plan how to deal with the errors: either by reinitializing the data (and possibly saving the currently captured rentals) or by fixing our system. Since we will run a number of tests on it, it could not possibly be a programming error. Right! 7.3.3. Determining UniquenessConsideration of migration brings up the issue of uniqueness. We have already determined how we need to access items in the collections: by a unique PhysicalID for the case of CDDisc and Customer , and by UPCCode for CDRelease . When we are adding items to these collections during migration (or at any other time), we should check that each item being added does not already exist in the target collection. If the item being added does exist, we need to make up a consistent rule for handling that condition: either to overwrite the existing item or to signal an error. For example, if you add a CDDisc that has the same PhysicalID as an existing CDDisc , you probably want to signal an error to let the user know there is a duplicate. On the other hand, Sam thinks some of his customers have multiple customer IDs. Since the system is paper based, it is hard to determine if that is the case. He figures that some customers who have been frequently late rental returners simply get another customer ID to start with a clean slate. When converting data from one system to the next, it is a good time to check for the uniqueness of that data, which brings up a new problem. We have to figure out a way to determine whether two customers are the same. We might rely on the Social Security number, if the customers are willing to give us one. We can use credit card numbers , but customers could give us a different card number each time. Email addresses are even worse . Customers can give us so many different ones, we could wind up with hundreds of records for the same person. The driver's license number might work, as long as the customer does not move in or out of state. Since that identification is good enough for the state and the feds, it is probably the most useful for Sam as well. In Sam's case, we might never know when a customer should be deleted from the collection. They could come back after a number of years to rent a CD. Customers who are refused rental privileges due to their excessive number of late returns or for other reasons should be kept in the collection forever so that Sam knows never to rent to them again. It seems like there are at least three categories of Customer s: Regular , Inactive , and NeverAgain . These definitely have different behavior. Whether these are represented as three separate classes, or as three states of a Customer , is something that we do not need to deal with at the moment. Sam has not even mentioned it in any of our talks. We will pass it by him after we finish the first iteration of the system.
|
< Day Day Up > |