Car Service Record Management System

On average, over 6 million passenger car accidents occur in the United States each year, and in the United States, there are around 239,100 auto repair and maintenance facilities. The data shows us that consumers in the United States spent a total of 194.9 billion dollars on services for their motor vehicles in 2021. This data is maintained by numerous third-party vendors and insurance firms, which may result in inaccurate or fragmented data. Therefore, a central system All the data that can be readily maintained is required. Our plan is to create a system that keeps track of auto maintenance, which will be helpful when buying or selling a certain car to learn more about it and its condition. This technology will assist in keeping track of data regarding used or accident-damaged vehicles. The idea of this project originated when one of our teammates had to solve this problem during an interview for a full-time software engineer Role.

We believe that the issues raised in the real-world scenario will be addressed by this project. Additionally, we think that there aren't any trustworthy mechanisms in place for keeping track of car maintenance records, which could affect both the price of a car overall and potential Buyers.

Without the appropriate architecture, the system is a little too complex to handle, and as more work proceeds, the complexity will only grow, making it more challenging to add new features, make adjustments, and optimize the code. The system's performance, scalability, usability, and manageability will all be directly impacted by the architecture, which will help define the system's overall integrity. We also need our system to have module-to-module interaction, data abstraction, and some additional functionality, and in order to do so, it is very important for us to pick the right architectural style.

(Figure 1) Car Workshop

The general public, insurance firms, and automobile manufacturing businesses are going to be the ones to utilize this system to keep track of car servicing information. First and foremost, everyone who is interested in purchasing a pre-owned automobile wants to make sure that they are receiving a good bargain on the vehicle. The insurance companies are the secondary users of this system. Then, before determining the rate for the car insurance, the insurance company would verify the history of the vehicle. Furthermore, the automobile manufacturing companies will manage the inventory for the various vehicle components based on the vehicles' service records.

1. Sarthak is a new doctoral student who wants to study math as his field of expertise. His home is a studio apartment that is located three miles away from the university. Although the local public transportation is pretty dependable where he moved to, getting around on the weekends, when bus frequency is greatly reduced, can be a little bit of a challenge. Because of this, it will be difficult to successfully plan all of the events around the bus schedule. But he does have another strategy to avoid that consequence. On the other hand, he may anticipate that his parents will come to see him during the winter holidays. In that case, he will want to be able to drive them to a variety of tourist destinations, so having a car will be of some use to him during that time. Given that he is pursuing a doctoral degree and that he is going to stay here for a while, another purchase that makes sense for him to make is that of a car. He starts looking for a new vehicle online and visits a number of different websites. When Sarthak discovered a deal that appeared to be too good to be true—the seller was trying to sell him an expensive car for a cheap price—he started to have some worries about the car's condition. The seller was offering to sell him the car for a low price. When it comes to this topic, our website can be of assistance. With the assistance of this, he will be able to establish whether the auto parts are original or not, whether the maintenance was routine or not, the condition of the car, and whether or not the automobile will require any prospective future servicing.




(Figure 2) Car Data in Records.



(Figure 3) User Use Case Diagram

2. Priyanshi is an analyst that works for a company that specializes in insurance. Every day, as part of her job, she looks at the condition of a car to figure out how much the insurance premium will be. To figure out how much insurance will cost, she has to think about more than thirty things, like the car's make, model, and year, as well as its previous owners, any accidents, any extra features, and any damage to the body. The problem is that she has to get all of the information by hand from a number of different third-party vendors and repair shops. Also, some data is missing from different places, and the format of the data varies from one vendor to another. Now, what she needs is a system with a central database that lets her just type in the license plate number of the car and see all the information from the database on the screen.




(Figure 4) Insurance Company Use Case Diagram

3. Automakers can view the data and determine which parts require greater maintenance. Rahul, who works for an auto parts manufacturer, wants to ensure that his business spends more time and money producing auto parts that are in high demand than those that are not. He was looking for a website that would assist him in making manufacturing decisions because his business was losing money because they were producing more headlights than necessary and there were very few sales of this component. So they could determine which parts of that specific automobile they needed to build in large quantities by using an online tool that Rahul could log into, enter the car model, and analyze.


(Figure 5) Car manufacturer Use Case Diagram

Based on the functionality that we have discussed in the system introduction and the use cases, we will be setting our requirements. Although the project's focus is only on websites, in the future we might broaden it to include desktop and mobile applications. The functional and nonfunctional requirements for this web application are defined below.

System Architecture

(Figure 6) Overview of our system

It is important for us to define modules in a way such that the application behaves in a cohesive manner and performs all the functionalities. The basic workflow of this application is as follows:

• Request Handler module: This module is responsible for handling the requests made by the client and validating them by either giving an invalid request response or continuing processing the requests.
• Authentication module: This module is responsible for authenticating the clients. This will make sure only certain users are given the permission to edit or update certain data on the website. Whenever a user tries to log into the website, they will first be authenticated, and then they will be logged in.
• DAO module: This module is responsible for connecting the database module through any request that is made. This module contains all the queries that will fetch all the data from the database. This is the only module that will connect to the database.
• Database: This module is responsible for providing all the functionalities of a database to the website. When a user requests a service, the website will pull up data that is stored in our database and display it to the user.

Database design

Databases are an important part of every web application because they provide the application with the ability to retrieve, store and handle all the data. There are several popular types of databases: relational, key-value, and document based with their own benefits and drawbacks. Relational databases are used to store the structured data.

The primary key for the majority of the entities defined in the data model will be a number. This identifier will be produced automatically by the database and won't reveal any extra information about the entity it represents. Using the IDs and a foreign key constraint, certain entities will relate to other entities. Additional restrictions will be set to enforce unique rules that will be defined for certain of the data stored in the system to ensure data integrity. Lastly, effective data retrieval is required. We shall define the necessary data indices for this. We will choose Azure SQL database service to host databases due to its superior cost and performance in comparison to other cloud providers.

(Figure 7) Database Design

Backend Design

For the backend we are using the REST API which will be crucial to the system's operation. It will provide a common language for dealing with the data and house the majority of the system's business logic.

DAO

DAOs help setting up the database connection and interacting with it by sending SQL CRUD commands.They also communicate with the clients to provide and obtain data.

(Figure 8)Car manufacturer Sequence Diagram

As we can see in the sequence diagram above, the car manufacturer client will interact with the web application when it tries to request login. The request handler will handle the request login information by authenticating the client and then validates the login by authenticating it. The authenticating module will send the request to DAO module will check if the email or password entered by the user is valid or not and then relates the status to request handler. Now, the car manufacturer client can enter the model of the car they want an information about and the request handler will send this request to REST API will send this request to DAO module. After receiving data from the database, DAO creates a model object or a list of model objects. Finally, DAO returns the model object(s) created to the client

(Figure 9) Insurance Company Sequence Diagram

In the sequence diagram above, the Insurance company client will interact with the web application when it tries to request login. The request handler will handle the request login information by authenticating the client and then validates the login by authenticating it. The authenticating module will send the request to DAO module will check if the email or password entered by the user is valid or not and then relates the status to request handler. Now, the insurance company client wil want information about different cars in order to decide the car insurance and for that they can enter the model of the car they want an information about and the REST API will send this request to DAO module. After receiving data from the database, DAO creates a model object or a list of model objects. Finally, DAO returns the model object(s) created to the client.

(Figure 10) Admin Sequence Diagram

In case of Admin Client, the admin will be able to login into the system and our website will authenticate this using the authenticate module provided in our website. Main functionality of Admin will be approving, authorizing and unauthorizing the different clients. Only he is given this access to update changes regarding this. The admin can enter the new details and request the changes to be made via the REST APIs and the DAO module will form a connection with the database to make these changes using UPDATE statement and the INSERT statements. And after the changes have been made a message will be displayed on the screen informing the admin in the form of model object(s).

(Figure 11) General User Sequence Diagram

In the sequence diagram above, the user will interact with the web application when it tries to request login. The request handler will handle the request login information by authenticating the client and then validates the login by authenticating it. The authenticating module will send the request to DAO module will check if the email or password entered by the user is valid or not and then relates the status to request handler. Now, the user can search the information about any model of any car by entering the model name and registration number of that particular vehicle. The corresponding information will be displayed on the screen and the user can also download pdf of the same if the requirement be.

(Figure 12) Workshop Sequence Diagram

In case of Workshop Owner Client, the user will be able to login into the system and our website will authenticate this using the authenticate module provided in our website. Main functionality of workshop owner will be adding, updating changes about the car maintenance records. The owner can enter the new details and request the changes to be made via the REST APIs and the DAO module will form a connection with the database to make these changes using UPDATE statement, INSERT statements and the SELECT statement. And after the changes have been made a message will be displayed on the screen informing the admin in the form of model object(s).

System Architecture Rationale

• It uses an architecture that has been proven to work for contemporary web apps.
• Separate layers make subsequent expansion less difficult. (that is, a single REST API may be utilized by a number of different front-end applications).
• Separation of code makes both development and maintenance much simpler.
• Scalability can be controlled separately by components.

Database Design Rationale

The relational database model is the one that we choose to use for the storage of the system's structured data. The main things that led to this conclusion were the level of development that relational databases reached and the ACID (atomicity, consistency, isolation, and durability) properties of these databases. In the end, what this comes down to is making sure that the data that is stored in the system is completely trustworthy.

We chose Azure SQL database service as our database platform because it can both run in the cloud and meet the need to standardize on a single platform. By using SQL standards, it may be possible to build the database without being tied to a specific database management system.Azure SQL database service platform is low-cost, scalable.

Web Application Design Rationale

The tech stack that we will be using for this will be React, HTML, JS, Java, and MySQL. A few significant advantages of developing the application as an Single Page Application (SPA) deliverable are - CDN can be used to develop and deploy the application, which will speed up the loading of HTML, JS, and other resources; we may create the user interface with React in manageable, reusable modules.

An alternative to our approach would be a more conventional web application such as using PHP, in which requests are made to a server, the pages are created, and then the user is redirected to them. With such a strategy, the loading of the Pages will be slower as we would need to connect our frontend application with the REST API application and extra resources will be required to handle the entire stack. The SPA strategy best meets our needs due to these factors.

The Car Service Record Management System is a system that is dedicated to users who want to get the details of the car that they want to buy, insurance companies that want to decide the insurance premium that they can charge, so they can decide that based on the data that they can get from the report of the car. Workshop owners can get the details of the part that is related to the car so they can fix that with ease as they have all the history of the car. Also, with the help of the data, factory owners can decide which particular part is in demand so they can produce that more and whichever part is in less demand, they can produce less. The system has 4 modules, i.e., the Request handler module, Authentication module, DAO module, and database module, which will handle different queries and output the appropriate results. The architecture that we followed for this project is layered architecture. A layered architecture will give us flexibility, maintainability, and scalability for the application and will provide easy reuse of the components. With the help of layered architecture, it's easy to keep these logical levels and parts focused on different things.