Reference no: EM131035655

THE REAL ESTATE MULTIPLE LISTING SERVICE SYSTEM

The Real Estate Multiple Listing Service system supplies information that local real estate agents use to help them sell houses to their customers. During the month, agents list houses for sale (listings) by contracting with homeowners. The agent works for a real estate office, which sends information on the listing to the multiple listing service. Therefore, any agent in the community can get information on the listing.

Information on a listing includes the address, year built, square feet, number of bedrooms, number of bathrooms, owner name, owner phone number, asking price, and status code. At any time during the month, an agent might directly request information on listings that match customer requirements, so the agent contacts the multiple listing service with the request. Information is provided on the house, on the agent who listed the house, and on the real estate office for which the agent works. For example, an agent might want to call the listing agent to ask additional questions or call the homeowner directly to make an appointment to show the house. Twice each month (on the 15th and 30th), the multiple listing service produces a listing book that contains information on all listings. These books are sent to all of the real estate agents. Many real estate agents want the books (which are easier to flip through), so they are provided even though the information is often out of date. Sometimes agents and owners decide to change information about a listing, such as reducing the price, correcting previous information on the house, or indicating that the house is sold. The real estate office sends in these change requests to the multiple listing service when the agent asks the office to do so.

Part 1:

Using the event list and ERD for that system as a starting point, develop the following object-oriented models:

1. Convert your ERD to a domain class diagram.

2. Develop a use case diagram.

3. Create a fully developed use case description or an activity diagram for each use case.

4. Develop a system sequence diagram for each use case.

Part 2:

Consider the requirements of the multiple listing service system developed in Chapters 5, 6, and 7. Assume that you're the project manager and that you work for a consulting firm hired by the multiple listing service to perform only the survey and analysis activities.

1. Assume that system users and owners have indicated a strong desire for a system that can be accessed "anytime, anywhere." Discuss the implications of their desire for the system scope. Given the preferences of the system users and owners, should you prepare a table similar to Figure 8-2?  Why or why not?

2. Discuss the implications of the anytime, anywhere requirement for the application deployment environment. What type(s) of hardware, network, and software architecture will be required to fulfill that requirement?

3. Investigate the availability of packaged and turnkey systems for multiple listing services. Search the Internet and real estate trade magazines and Web sites. Discuss the pros and cons of choosing a packaged or turnkey system.

4. Develop an RFP outline that covers packaged, turnkey, and custom-developed systems. What are the difficulties of writing one RFP that covers all three scenarios? Who should be involved in evaluating RFP responses?

THE STATE PATROL TICKET PROCESSING SYSTEM

The purpose of the State Patrol ticket processing system is to record driver violations, to keep records of the fines paid by drivers when they plead guilty or are found guilty of moving violations by the courts, and to notify the court that a warrant for arrest should be issued when such fines are not paid in a timely manner. A separate State Patrol system records accidents and verification of financial responsibility (insurance). Yet a third system produces driving record reports from the ticket and accident records for insurance companies. Finally, a fourth system issues, renews, or suspends driver's licenses. These four systems are obviously integrated in that they share access to the same database, but otherwise, they are operated separately by different departments of the State Patrol. State Patrol operations (what the officers do) are entirely separate.

The portion of the database used with the ticket processing system involves driver data, ticket data, officer data, and court data. Driver data, officer data, and court data are used by the system. The system creates and maintains ticket data. Driver attributes include license number, name, address, date of birth, date licensed, and so on. Ticket attributes include ticket number (each is unique and preprinted on each sheet of the officer's ticket book), location, ticket type, ticket date, ticket time, plea, trial date, verdict, fine amount, and date paid. Court and officer data include the name and address of each, respectively. Each driver may have zero or more tickets, and each ticket applies to only one driver. Officers write quite a few tickets.

When an officer gives a ticket to a driver, a copy of the ticket is turned in and entered into the system. A new ticket record is created, and relationships to the correct driver, officer, and court are established in the database. If the driver pleads guilty, he or she mails in the fine in a preprinted envelope with the ticket number on it. In some cases, the driver claims innocence and wants a court date. When the envelope is returned without a check and the trial request box has an "X" in it, the system notes the plea on the ticket record; looks up driver, ticket, and officer information; and sends a ticket details report to the appropriate court. A trial date questionnaire form is also produced at the same time and is mailed to the driver. The instructions on the questionnaire tell the driver to fill in convenient dates and mail the questionnaire directly to the court.

Upon receiving this information, the court schedules a trial date and notifies the driver of the date and time.

When the trial is completed, the court sends the verdict to the ticketing system. The verdict and trial date are recorded for the ticket. If the verdict is innocent, the system that produces driving record reports for insurance companies will ignore the ticket. If the verdict is guilty, the court gives the driver another envelope with the ticket number on it for mailing in the fine.

If the driver fails to pay the fine within the required period, the ticket processing system produces a warrant request notice and sends it to the court. This happens if the driver does not return the original envelope within two weeks or does not return the court supplied envelope within two weeks of the trial date. What happens then is in the hands of the court. Sometimes the court requests that the driver's license be suspended, and the system that processes drivers' licenses handles the suspension.

Part 3:

Refer to the description of the State Patrol ticket processing system. Using the event list and ERD for that system as a starting point, develop the following object-oriented models:

1. Convert your ERD to a class diagram.

2. Develop a use case diagram.

3. Create fully developed use case descriptions for two of the primary use cases, such as Recording a traffic ticket and Scheduling a court date.

4. Develop system sequence diagrams for those same use cases.

5. Develop a state machine diagram for a ticket.