Software Engineering Milestone Project
Objectives of the Project - The purpose of this project is to reinforce the concepts discussed in class. The project gives you the opportunity to practice the concepts and techniques taught in the class on a realistic problem. The main objectives of the project are to practice the Requirements Specification, and OO Analysis and Design Modeling for a software solution to a problem.
Background - Ms. Fatima Ahmed is the new Director of the Qatar Vehicle Registration (QVR) department. Currently, the department provides various services such as renewal of vehicle registration, transfer of ownership, managing compulsory insurance policies, fitness certificate, accident, and penalty. At the moment, these services are not available online to the general people. Ms. Fatima has decided to offer its major services online called iQVR to the general public in Qatar. Your group has been contacted recently by Ms. Fatima to develop the online system for iQVR department. She has prepared a description of the major functions that are expected to be available online. She reminds your team that the scope of your analysis and design tasks and the system boundary is QVR only.
Currently, iQVR has five sections: Finance section deals with payments, Penalty section handles fines and offences, Registration section processes renewal and ownership transfer, Accident section deals with all accident matters, and Technical section manages the fitness of vehicles. The department has a computer-based system that manages all payments, and salary of the employees. This is a standard, commercial-off-the-shelf package called qPay. Now, Ms. Fatima wants to replace all five sections with an automated online system, but wants to keep qPay as a separate system connected to iQVR. She plans to employ only one system administrator to handle this automated process. iQVR should work as described below.
The vehicle owners, insurance companies, and authorized workshops must need the login ID and password for the online service of iQVR. It is assumed that by default every user has already logged in, so login is not a functionality of the system that your team should design or develop.
In order to register a new vehicle or renew the registration, a vehicle owner first buys an insurance policy from an insurance company. Once an insurance policy for a vehicle is bought from an insurance company, the policy of the insurance is immediately recorded in the iQVR system. A vehicle must have an insurance policy, and an insurance policy is valid for one vehicle. The company enters VIN(Vehicle Identification Number) to the system, and attaches the copy of the policy. The system simply records this information with the company data, and produces an acknowledgement receipt for the company. If the vehicle is more than two years old, it needs a fitness certificate from an authorized workshop in Qatar. Once a vehicle gets a fitness certificate, the workshop submits the fitness certificate online to the iQVR system by entering the VIN, certificate number, and attaching a copy of the certificate. One certificate is valid for only one vehicle, however, a workshop can issue many certificates. The system stores these with the workshop data, and generates an acknowledgement receipt for the workshop. A registered vehicle can have only one current owner, however, an owner can have more than one vehicle.
In order to transfer the ownership of a new unregistered vehicle (not registered before), to another person, the current owner enters the VIN to the system, vehicle make, model, and year of make. The system provides VIN and car details to another system run by the vehicle manufacturer company that verifies immediately with its factory database if the VIN and other specifications are correct. If the response is positive from the manufacturer, the iQVR system asks the current owner to supply his/her name and QID. Otherwise, it terminates the session with a message "Incorrect vehicle information." The iQVR system then communicates with another system run by Qatar Trade Service with the VIN and QID of the current owner to check if this owner imported the vehicle from overseas. Qatar Trade Service checks its file to find the vehicle and provides a response to iQVR. If the response is positive, the system then finds the insurance policy of the vehicle already submitted by the insurance company. If the response is negative, the system terminates the session with a message "Incorrect ownership." If the insurance policy exists, the system concurrently generates a registration number for the vehicle, assigns this to the vehicle, and displays the number to the owner. Now the current owner provides the name, QID, address and mobile phone of the new owner. The system records these, and assigns the vehicle to the new owner. It sets the current owner as 'previous owner' and the new owner as the 'current owner' concurrently. The system then confirms the ownership transfer by generating a new registration sticker, and creates an invoice (bill) for the transfer fee for the new owner to pay later.
However, to transfer a registered vehicle to another person, the current owner enters the VIN of the registered vehicle and the QID number of the current owner, the system first finds the registration details of the vehicle. If the retrieved information does not match with the provided data, the system terminates with the message "Incorrect Information," otherwise it initiates the transferring process. The system checks if the vehicle has any unpaid invoices (bills) for registration fee or fines for traffic offenses. If there is any, the system terminates the session with a message "Pay the bills first." The payment procedure is explained later. If there are no unpaid dues, the system requests for the details of the new owner. The current owner provides the name, QID and mobile phone number of the new owner. The system assigns the vehicle to the new owner, sets the current owner as 'previous owner' and the new owner as the 'current owner'. The insurance policy already assigned to the vehicle during the last registration remains unchanged. However, the new owner can change the insurance policy later. The system then confirms the ownership transfer by generating a new registration sticker, and creates an invoice for the transfer fee.
For the renewal of a registered vehicle, the vehicle owner enters the VIN to the system. It retrieves the registration details and checks if the vehicle is more than 2 years old. If it is, the system finds the vehicle fitness certificate issued by an authorized workshop. The system terminates with a message "Get fitness certificate first", if the fitness certificate is not available. If the certificate exists, it retrieves the compulsory insurance policy of the vehicle issued by an insurance company. If a new insurance policy is available, the system checks for any unpaid fines for traffic offenses; otherwise terminate the system with a message "Get insurance policy". If there is any unpaid fine(s), it asks the owner to pay the fine(s) with a message "Pay the bill first. If there are no unpaid fine(s), the system creates a new registration with the same validation period as specified in the new insurance policy. The insurance policy and the fitness certificate are then attached concurrently with the vehicle registration. The system then prepares a new registration sticker with new validity. It finally creates an invoice for the registration renewal.
For an accident between only two vehicles, if a vehicle accepts that it was his/her fault, he/she enters VINs of his/her and other vehicle (victim). The system finds vehicle details and registration information of both vehicles. The system then asks to provide the date, time, location, and a brief description of the accident. The system records this information, and by default it sets that the vehicle who entered all information is the owner of the offending vehicle, and other vehicle is the victim of the accident. The system asks the owner of the offending vehicle to confirm this. Once confirmed, the system stores this. The system then concurrently finds the insurance policy of the offending vehicle, and creates an accident report with a unique case number. The iQVR system then sends the accident report to the insurance company that immediately sends an acknowledgement receipt that is saved by the iQVR system. The accident report is then stored, and available for both parties (owners of the offending and victim vehicles) to retrieve at any time. Any authorized workshop can retrieve the accident report if the case number is known. However, if there is a dispute regarding an accident, no online reporting is allowed. Both parties must go to a police station to solve the dispute.
Vehicle owners can pay any unpaid invoices or fines for a vehicle using a credit card. In order to pay, the owner provides the VIN, credit card details such as number, name of the cardholder, and validity. The system retrieves the vehicle registration details. If the registration details do not exist, the system displays an error message and asks to enter a correct VIN. Otherwise, it lists unpaid invoice(s), if there is any. The owner then selects which of the invoices and fines he/she wants to pay. The system saves the selection, computes the total amount, then forwards the card details and the total amount to the qPay system for approval. qPay is a separate software system, but owned by the OVR department. The qPay checks for the validity of the card by contacting the credit card provider (bank). If the card is invalid, it generates an error message to iQVR without processing the payment. Otherwise, qPay returns an approval advice to iQVR. For invalid credit card, iQVR asks the owner to enter valid credit card details. The iQVR system records the outcome sent by qPay. It then concurrently records approval number, prepares a payment receipt, and sets the invoice(s) as paid. It then displays the receipt. Finally, the system updates the list of the unpaid invoices associated with the vehicle.
The traffic police can find out which vehicle has how many red-light offenses in last one year or one month or one week. He/she enters the period(day, week, month), and selects the redlight offense type from the system. Based on these criteria, the system finds a list of vehicles that match these criteria. The traffic police selects those vehicles that exceed a certain number of red-light offenses during this period. The system creates confiscating order for those vehicles, and asks for confirmation from the traffic police. It saves the confirmation, cancels registration of those vehicles, and informs the owner of each vehicle. The owner receives the order. The system then broadcasts the orders to all police departments. A confiscating order is attached with only one vehicle, however, one vehicle can get more than one order.
The system knows the registration details of vehicles, model and the make of each vehicle; previous and current owners of each vehicle such as their name, QID, address. It also knows the insurance policy of every registered vehicle such as policy number, validity, and the name of the contact details of the issuing company of the policy. A company can sell many insurance policies. The system also stores information about the fitness certificate of each registered vehicle and the details of workshop that issued the certificate. It keeps information about the invoices, fines, traffic offences and the involving vehicles. The system knows details of each accident such as date, time of the accident, and the involving vehicles. However, it does not record any information about the traffic police except their login data. The system keeps records of all acknowledgements and responses that it received from external systems.
Currently the proposed system can handle 10 million vehicles. However, it is projected that the traffic system will have more than 30 million vehicles within next 10 years. More new functionalities need to be added to the system, some existing ones might be modified or deleted to enhance further capabilities. The core data about the vehicles and the ownership details are confidential, these should not have direct exposure to any general user-level functions. These need to be protected by separating them from the high level user interface. The software could be portable, that means, it can run on varieties of machines such as mobile phone, tab, desktop, etc. Time to time, some functions may need upgrading and modifications, but the interfaces to the rest of the system may remain same. The software could be distributed in future; different components may run on different machines in different locations. Several backup modules will be managed in order to support availability of the systems to the users most of the time. Various components of the software should be less dependent on each other and more focused.
The traffic police department does not have budget for more than 10 new technical staff for the project. It has budget for only 20 new servers. The system must run as plug-in for the registration system that uses Oracle database system for data management. Most functions of were developed using Java and C. The traffic police department has qualified staff experienced with Oracle, Java and C. The first version of the system should be completed within 3 months. Any delay will cost money of the traffic department because the system is expected to start operating exactly after 12 months.
Tasks of Your Project -
Milestone 1: Requirements Analysis
This project concentrates on the technical aspects of the software engineering process, and hence emphasizes the analysis and design components developed during the process. The focus of this Milestone-1 is on the requirements analysis to produce the Use case model, the class diagrams and the system interaction models using the Unified Modeling Language (UML) and Visual Paradigm tool. The body of your Milestone 1: Requirements Analysis and Design will consist of the following deliverables:
1. Propose:
a. A data flow diagram (DFD) of the system: include major processes, data files, data elements, and external entities.
b. A use case diagram of the system:
c. Explain which of these two methods you prefer best to analyze a system and why.
2. Develop use case specifications for most complex and key 5 use cases selected from your use case diagram. Your proposed each use case specification should include brief description, primary actor(s), trigger, pre-condition(s), post-condition(s), normal scenario (actor action-system response table), alternative flows (if any). Use the "Use cases specification template" available from Blackboard.
3. Complete design class diagram with all required classes, their attributes and types, relationships (aggregation, generalization, association) with multiplicity where applicable, methods with major parameters, and visibility of attributes and methods.
4. Prepare design sequence diagrams for all 5 use cases proposed in Task 2.
Any assumptions you made regarding the system description. Assignment components will be evaluated for accuracy, clarity, relevancy, and completeness (especially among components and among artifacts) of your document.
Attachment:- Assignment File.rar