7.3. Migrating to the New System

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 Data

For 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: ^[*]

^[*] Readers may note that putting these methods into the collections is a poor separation of concerns. Tim noted this issue and the methods were placed in separate classes, as you will see in the next chapter. Eric M. Burke, a reviewer, noted that the Apache Ant system was designed with knowledge of the XML project structure. Ant code cannot be easily reused with anything but an XML project.

 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.

FIGURE OUT HOW TO MIGRATE BEFORE YOU MIGRATE

Considering the migration path might help you discover additional considerations in other areas of the design . ^[*]

^[*] A reviewer noted that this is discussed in Rapid Development by Steve McConnell (Microsoft Press, 1996).

7.3.2. Anticipating Potential Problems

A 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:

• The ID on a physical CDDisc does not appear on the inventory

• The title on a physical CDDisc does not match the title on the inventory

• There is a CDDisc on the inventory report that does not appear in the physical inventory

• The status of a CDDisc on the inventory report does not match the physical inventory

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 Uniqueness

Consideration 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.

KNOW WHO IT IS

Determine uniqueness criteria for objects that should be unique .

THE UNIQUE PASSENGER

When you take a commercial flight, the attendant checks to see that your identity matches the name on your ticket. When you make a reservation for a restricted ticket, you need to give your real name or else the ticket that is issued will not match your identity. However, for full-fare reservations placed through a travel agency, there was a little-known backdoor. You could change the name on the reservation up until the time the ticket was actually issued. Since the ticket did not need to be issued until immediately before the flight, the name could be changed up until that time.

If a passenger wanted to reserve a seat on a number of flights , his travel agent reserved the seats under different names . When the passenger finally picked the flight, the name on that reservation was changed.

Those who designed the reservation system wanted to determine if two passenger reservations with different names represented the same actual passenger. This turned out to be almost impossible to infer definitively. There was no easy way to determine the uniqueness of a passenger.