You are an independent consultant who has been hired to create a software application for a local real estate agency. The realtor wants to store all his customers along with their mortgage information, and he wants to look them up if he needs to. He also wants to keep track of when customers make payments so he can tell them how they are progressing with their mortgages. Finally, he wants to be able to search for a customer by name or id so he can pull up their records and access their mortgage quickly.

Your job is to design an application to accomplish these objectives. The realtor provides you with the following information:

Customers

A customer has a unique ID, a first and last name, address, and contact information, i.e. a telephone number or an e-mail address. The realtor only works with customers in the United States and Canada. Since mortgages are calculated differently in these two countries, he needs to know which country the customer lives in. Finally, a customer has one or more mortgages.

Mortgages

A mortgage belongs to a customer, but it has its own unique id. That way, the realtor can easily search for a specific mortgage or a specific customer. Every mortgage has an annual interest rate from 1 to 100 percent, principal (the initial amount of the loan), and the length of the loan in years. The mortgage should also have a payment history that stores payments. Each payment has a date and an amount. The realtor must be able to obtain the monthly payment for the mortgage. He also wants to be able to tell the customer his/her remaining principal on the mortgage given the number of payments already made. We can assume that each payment made is equal to the fixed amount.

The formula for calculating the monthly payment for a U.S and Canadian mortgage is at this web site: http://www.hughchou.org/calc/formula.html. You can also find the formula for the total remaining payments on this page.

The program should allow the realtor to add, edit and delete customers. Just to be safe, the realtor doesn't want to be able to delete a customer if he/she has mortgages without asking for verification first. As far as the mortgages go, once a mortgage is created, the program shouldn't let the user edit its terms. However, the Realtor does want to be able to "play" with the terms to see how it would affect the monthly payments. That said, the temporary changes made should not be saved. If the user wants to delete a mortgage, the program needs to ask for confirmation.

Searches

The realtor wants to be able to do a quick search for a customer given their ID or their name. He also wants to be able to quickly look up a mortgage if he knows the ID of the mortgage. In either case, when a match is found, the program should show the customer, the mortgages, and then hone in on the specific mortgage if that's how the realtor did the search. If the realtor searches by customer, the first mortgage stored is fine. Almost all of his customers will only have one mortgage, but the program has to be able to handle more than one since some customers have multiple properties.

Odds and Ends

The realtor wants to make sure all the data entered is valid. So make sure nothing can be entered and saved that is out of range or invalid. He also wants the data stored in a file that he will regularly back up himself. The data should be saved whenever a transaction is made rather than held until the program closes down. That way if the user makes a bunch of changes and suddenly the power goes out, he won't lose all of his work. The data should get loaded into the program when it is first run. You have a custom of placing a menu in your main window that has File - Exit and Help - About at a minimum. The Help - About menu should bring up a modal dialog that lists, at a minimum, who wrote the program and when it was written.

Design

The design of the program is completely up to you. I suggest that you break the features down in the order that you would like to implement them, and then iterate through them (implement feature / test / demo / implement / test / demo). In our case, demos will be held once per week in class. Please follow the guidelines shown below, as you will be graded on the quality of the code you write as well as the quality of the user experience.

Assessment

Your program will be assessed on the following three criteria:

· The customer's requirements are fully met (50%)
· The quality of the user experience (25%)
· The quality of the code itself (25%)

Obviously, the program has to do what the customer wants, so the first criterion will carry the most weight. With regard to the second item, there are easy-to-understand, clean, simple ways to do things, and difficult, non-intuitive, cluttered and confusing ways. Part of your grade will be determined by how simple the program is to use, how easy it is to work with the user interface, and how fault tolerant the program is. Here are some helpful guidelines with regard to the user interface:

1. This program is going to be used to enter customers and their mortgage(s) as well as to look up existing customers and their mortgages to add payments and obtain information. Do not try to do everything in one great, big window. Divide up tasks in a way that makes sense, giving the user clear options along the way.

2. Think of a dialog like a room. You go into the room for a specific task, and then you get out back in to the main room. Always make sure dialogs do one specific thing for the user and that they can OK or Cancel out of the dialog.

3. Your main window should have a menu with File - Exit and Help - About at a minimum. The Help - About menu should bring up a modal dialog that lists, at a minimum, who wrote the program and when it was written.

4. Do not store items into list boxes. Instead, put them into collections. If the user wants to find a specific customer, the customer's name or id should be entered. Putting everything into a list box is not practical when you have thousands of customers.

5. Your program should require the user to think as little as possible about the mechanics and navigation of the program itself, letting the user focus on the data he or she wants to obtain and manipulate.

You will also be graded by the quality of the code you write. Here are some guidelines for the program itself:

1. Your program should use classes and objects, inheritance, polymorphism, collections that use generics, and exceptions. How you use these tools is up to you, but your goal is to reduce complexity and, most of the time, less lines of code. I say most of the time because there is a balance. You can try to do everything in one line of code, but it might be clearer if you write it in three lines.

2. Create, at a minimum, the following entities:

a. A Mortgageclass that contains all of the necessary properties and methods. Put all your calculations in this class or one of its child classes if you wish to use inheritance.

b. Use strongly-typed collections to store your Customers, Mortgages, Payments, and anything else that you have multiple copies of.

c. Use composition, i.e. put objects inside of objects.

d. Use exception handling to anticipate and handle errors and problems such that the program does not crash under any circumstances from user input.

e. Use file I/O to store the data for the program, placing the file in the same folder as the executable.

3. Avoid duplication of code wherever possible. Class inheritance is a good way to accomplish this.

4. If you use inheritance, and you have base classes that are too generic to be used on their own, make sure they are marked MustInherit.

5. If a method doesn't rely on a specific instance of an object, mark it Shared.

6. Calculated data should be supplied via methods, not properties. If, when a method is called, one or more properties you need is not set, throw an exception stating which properties must first be set.

7. Use error handling throughout the program to ensure errors are caught and properly dealt with. The program should never "crash" no matter what kind of data it is fed.

8. Use class serialization to store all of your data into a file. When the program closes, save the data, and when the program opens, load it back in. You may need to do some research on serialization and file I/O if this is new to you. Research is a normal part of programming. We often run into things we need to do that we've never done before. And so this is good practice at figuring out new concepts by accessing helpful resources.

9. Documentation is very important in programming. We all hate to do it at the time, but years later when you look back at your program, you will be very glad you did. So be sure to add in comments wherever appropriate.