THE STATE PATROL TICKET PROCESSING SYSTEM by iqbiU0h7

VIEWS: 0 PAGES: 3

									          Graduate of School of Information, Computer and Communications Technology
                               IT 280 – Software Design and Development
                                              Term Project
                                                   Instructor: Jasmin A. Tumulak, MSIT
                                             jasmine@usjr.edu.ph, piperhuntress@yahoo.com

THE STATE PATROL TICKET PROCESSING SYSTEM

         The purpose of the State Patrol ticket procession 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 of 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 drivers’
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-procession system involves driver date, ticket
date, officer date, and court date. Driver date, officer date, and court date are used by the system. The
system creates and maintains ticket date. 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 date 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-procession 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.



Graduate of School of Information, Computer and Communications Technology
IT 280 – Software Design and Development
Term Project
Deliverables based on the Unified Process Disciplines:
   I.   Business Modeling
        a) Given the case background, make a list expected system objectives, business benefits and
             system capabilities for the State Patrol Ticket Processing System.
        b) Develop a work breakdown structure for the case above.
        c) Build a Gantt chart using MS Project or any project management tool. Identify the tasks,
             dependencies and durations. Give your own assumptions. Print out both the PERT chart
             and Gantt chart.
  II.   Requirements
        a) To what events must the ticket processing system respond? Create a complete event table
             listing the event, trigger, source, use case, response, and destination for each event.
        b) Draw a class diagram to represent the domain model for the ticket-processing system,
             including the attributes mentioned. Explain why it is important to understand how the
             system is integrated with other State Patrol systems.
        c) Draw a class diagram to extend the domain model that assumes there are different types of
             drivers. Classifications of types of drivers vary by state. Some states have restricted licenses
             for minors, for example, and special licenses for commercial vehicle operators. Research
             your state’s requirements, and create a generalization/specialization hierarchy for the class
             Driver, showing the different attribute each special type of driver might have. Consider the
             same issues for types of tickets. Include some special types of tickets in a
             generalization/specialization hierarchy in the class diagram.
        Using the event table and domain class diagram for that system as a starting point, develop the
following object-oriented models:
        d) Develop a use case diagram.
        e) Develop fully developed use case descriptions for two of the primary use cases, such as
             Recording a traffic ticket and Scheduling a court date.
        f) Develop an activity diagram for each use case.
        g) Develop a system sequence diagram for each use case.
        h) Based on the information provided in the case, develop a statechart for a ticket.
        Consider the requirements of the State Patrol Ticket Processing System. Assume that you are
the project manager and that you work for a consulting firm hired to perform requirements and
architectural design activities. Assume that system users and owners have indicated a strong desire for a
system that can be accessed “anytime, anywhere.”
 III.   Design
     a) 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?
     b) Develop a three-layer architecture using ordinary PCs running Web browsers to implement the
        view layer. Draw a network diagram to represent your solution.
     c) Today’s computer-based real estate listings typically include graphical date, such as still and
        moving pictures in addition to text descriptions of properties. What is the impact of such data
        on date-communication requirements within your network design, assuming 10 listing accesses
        per hour? 100 listing accesses per hour? 1,000 listing accesses per hour?
        Based on the use case diagram, fully developed use case descriptions and activity diagram, and
        system sequence diagram for the real estate company’s use cases:
     d) Develop a first-cut sequence diagram for the problem domain classes.
     e) Next, add view layer and data access layer objects to the sequence diagram.

Graduate of School of Information, Computer and Communications Technology
IT 280 – Software Design and Development
Term Project
     f) Convert the domain class diagram to a design class diagram by typing the attributes and adding
        method signatures.
     g) Using the class diagram for the system as a starting point:
            a. Develop a relational database schema in 3NF.
     h) Create a set of menu hierarchies for the system based on the use cases in the case study. Then
        add more hierarchies for system utilities based on controls, user preferences and help.
     i) Develop a user interface design by implementing a prototype for the State Patrol Ticket
        Processing System. The objective of the prototype is to show the user interface design and
        thus, implementation is not a must.




Graduate of School of Information, Computer and Communications Technology
IT 280 – Software Design and Development
Term Project

								
To top