Automotive System

Kevin Allen, Abraham Jimenez, Jesus Ortha and Juan Perez

C ONTENTS XII Object Diagram 5

XII-A Diagram . . . . . . . . . . . . . . . . . 5
I Introduction 1 XII-B Description . . . . . . . . . . . . . . . . 5
I-A Purpose . . . . . . . . . . . . . . . . . . 1
I-B Scope . . . . . . . . . . . . . . . . . . . 1 XIII Component Diagram 5
I-C Overview . . . . . . . . . . . . . . . . . 2 XIII-A Diagram . . . . . . . . . . . . . . . . . 5
XIII-B Description . . . . . . . . . . . . . . . . 5
II General Description 2
II-A Product Perspective . . . . . . . . . . . 2 XIV State Diagram 5
II-B Product Functionality . . . . . . . . . . 2 XIV-A Diagram . . . . . . . . . . . . . . . . . 5
XIV-B Description . . . . . . . . . . . . . . . . 6
III Constraints 2
XV Colaboration Diagram 6
IV Assumptions and Dependencies 2 XV-A Diagram . . . . . . . . . . . . . . . . . 6
XV-B Description . . . . . . . . . . . . . . . . 6
V Foreseeable System Evolution 2
XVI Development Log -Second Project Progress 6
VI Functional Requirements 2 XVI-A Log In . . . . . . . . . . . . . . . . . . 6
VI-A Functional Requierment 1 . . . . . . . . 2 XVI-B Menu . . . . . . . . . . . . . . . . . . . 6
VI-B Functional Requierment 2 . . . . . . . . 2 XVI-C Spare Parts . . . . . . . . . . . . . . . . 6
VI-C Functional Requierment 3 . . . . . . . . 2 XVI-D Car List . . . . . . . . . . . . . . . . . 7
VI-D Functional Requierment 4 . . . . . . . 2
XVI-E Car Sale . . . . . . . . . . . . . . . . . 7
VI-E Functional Requierment 5 . . . . . . . . 2
XVI-F Price Previe . . . . . . . . . . . . . . . 7
VI-F Functional Requierment 6 . . . . . . . 3
XVI-G Data Base . . . . . . . . . . . . . . . . 7
VI-G Functional Requierment 7 . . . . . . . . 3
XVI-H Possible Incidents and Solutions . . . . 7
VII Non-Functional Requirements 3 XVI-I Next Steps . . . . . . . . . . . . . . . . 7
VII-A Non Functional Requierment 1 . . . . . 3 I. I NTRODUCTION
VII-B Non functional Requierment 2 . . . . . 3
VII-C Non functional Requierment 3
VII-D Non functional Requierment 4
.
.
.
.
.
.
.
.
.
.
3
3 I N this document, we will present our initial progress on
our project for the Database Topics class. The purpose of
this document is to outline the functional and non-functional
VII-E Non functional Requierment 5 . . . . . 3
requirements of the software we will develop throughout
VII-F Non functional Requierment 6 . . . . . 3
this course. The software to be presented in this case is an
VII-G Non functional Requierment 7 . . . . . 3
automotive system that will handle insurance, appointments,
VIII ER Diagram 3 spare parts, and car sales.
VIII-A Diagram . . . . . . . . . . . . . . . . . 3 A. Purpose
VIII-B Description . . . . . . . . . . . . . . . . 3
The purpose of this software is to distribute requested spare
IX Class diagram 4 parts, schedule appointments, offer insurance to customers,
IX-A Diagram . . . . . . . . . . . . . . . . . 4 and, in general, handle vehicle sales, all registered in the
IX-B Description . . . . . . . . . . . . . . . . 4 database for control and management.

X Physical Diagram 4 B. Scope

X-A Diagram . . . . . . . . . . . . . . . . . 4 • Efficiency in Inventory Management: Ensuring an up-
X-B Description . . . . . . . . . . . . . . . . 4 dated and optimized inventory to guarantee spare parts
availability at all times, avoiding losses due to excessive
XI Use Case Diagram 4 inventory or out-of-stock situations.
XI-A Diagram . . . . . . . . . . . . . . . . . 4 • Insurance Sales: Providing a platform to compare and
XI-B Description . . . . . . . . . . . . . . . . 5 purchase auto insurance, offering detailed information
 about available options and assisting customers in making IV. A SSUMPTIONS AND D EPENDENCIES
informed decisions. • Operating System Availability: It is expected that, through
• Car Sales: Facilitating the search, viewing, and purchase software development, recent versions of the desired
of new and used vehicles, including detailed pricing, operating system will still be predominant in the market.
specifications, and financing options. • Network: The software is planned to have a stable and
• Customer Experience: Prioritizing customer satisfaction secure network infrastructure, which is essential for real-
through effective customer service, technical support, and time operations.
seamless purchase processes. • Access to Inventory Data: It is assumed that access to a
• nalytics and Reporting: Collecting and analyzing data reliable and up-to-date database of spare parts for vehicles
on user interaction with the platform to gain valuable from different brands and models is available, as this is
insights into customer behavior, marketing campaign ef- essential for enabling parts search and purchase.
fectiveness, and inventory management. • Data Security: It is assumed that robust data security
measures have been implemented to protect users’ confi-
C. Overview dential information, such as personal and financial data.
• Marketing Strategy: Relying on an effective marketing
This system is being developed to be user-friendly and
strategy to attract users and generate sales.
easy to use, providing a simple interaction with users and
maintaining constant updates with the database to prevent data V. F ORESEEABLE S YSTEM E VOLUTION
loss. We will showcase an easy-to-understand interface that
• Mobile and Applications: The development of mobile
displays the various established options.
applications could be a natural evolution, allowing users
to access services more conveniently from their mobile
II. G ENERAL D ESCRIPTION devices.
• AI Integration and Automation: The incorporation of ar-
A. Product Perspective
tificial intelligence and automation could enhance system
The dealership’s program will be software designed to efficiency. For example, a chatbot or virtual assistant
facilitate the purchase of vehicle parts and vehicles themselves, could provide online support to users and assist in spare
among the options mentioned earlier. It will be managed parts searches.
through a database that will be constantly updated. This • Expansion of Target Market: In addition to individual
software is open to future design or structural improvements. consumers, the system could target vehicle rental com-
panies, dealerships, and other market segments.
B. Product Functionality VI. F UNCTIONAL R EQUIREMENTS
In general, the software will verify the availability of spare A. Functional Requierment 1
parts for sale, as well as vehicles, appointment scheduling, Spare Parts Search: Users must be able to search for
and insurance sales, all of which will be recorded and verified spare parts by brand, model, vehicle type, part number, and
in the database. Sales and software usage analysis will be description.
performed for future improvements.

III. C ONSTRAINTS B. Functional Requierment 2

Insurance Comparison: The program should allow users to
• Programming Language: The application is developed compare different auto insurance options, including coverage,
exclusively for use within the dealership, so the primary price, and terms.
language to be used will be Python.
• Hardware: The software operates with a manager’s ac- C. Functional Requierment 3
cess for editing and updating information directly in the Vehicle Listings: It should display detailed listings of
database, and for employees who record sales and update vehicles for sale, including images, technical specifications,
stock quantities to prevent overselling. and prices.
• Operating System: Efforts will be made to ensure com-
patibility with various operating systems, but it will be D. Functional Requierment 4
primarily designed for Windows 10 and later. Inventory Management: The system must track spare parts
• Specific Standards: All transactions and the storage of and vehicle inventory in real-time, automatically updating
personal data must comply with data protection regula- when a purchase is made.
tions such as GDPR and other local privacy laws.
• Development Methodologies: An agile methodology, E. Functional Requierment 5
such as Scrum, will be adopted for software development, Payment Integration: It should support various payment
with regular iterations and reviews. methods, such as credit cards and bank transfers.
F. Functional Requierment 6 VIII. ER D IAGRAM

Notifications and Reminders: It can send email or text A. Diagram

notifications to confirm appointments, provide maintenance
reminders, and track purchase orders.

G. Functional Requierment 7

Data Security: It must ensure the security of users’ personal

and financial data through encryption and strong security
practices.

VII. N ON -F UNCTIONAL R EQUIREMENTS

A. Non Functional Requierment 1

Performance: The system must be highly responsive, with

fast load times and smooth performance even during periods
of high demand.

B. Non functional Requierment 2

Security: It must comply with security standards, including

protection against cyberattacks, fraud prevention, and user data B. Description
security. As we can see, this diagram is masive, non the less its
comprensible and have an order; We are going to start with
the employe, the client and the administrator, all of the can
C. Non functional Requierment 3 enter the main page of the program, but not everyone can enter
Scalability: It should be scalable to handle future traffic the main menu or the system, for example, the client can only
and user demand growth. see the main page for information, it will not be a program
that can be access from anywhere, it will be only shown for
make apointments by the employe. The employe can access
D. Non functional Requierment 4 the login page and access some of the funtions like the stock,
the sales and the insurance, but cant access the modification
Usability: It should be user-friendly with an intuitive inter- funtions of the program. The admin will have access for every
face for users of all experience levels. funtion of the program. Now how the program intract with
itself, starting from the system, we can interact with the funtion
sales, finances, insurances,archive and inventory, Sales only
E. Non functional Requierment 5
stores like the names imply, the sales of the department. next
Maintainability: It should be easy to maintain and update we have the finances, in it we can store the monthly balance,
with new features and bug fixes. as well as the income and expenses of the department. Next
we have the insurance, in the insurance we divide it by two
types of insurance, Normal cover and full cover, like the name
F. Non functional Requierment 6 implies, one can only covers minor damages, and the full
cover aply to the full extent of the damages. Coming over
Regulatory Compliance: It must comply with all local and to the system, we can go to the inventory, it is conected to
national regulations related to vehicle sales, insurance, and supplier, cars and the stock. the inventory have 3 main parts
user data. that divides the spare parts, the front parts, the inside parts,
and the bottom parts. the front parts have nine entities, the
G. Non functional Requierment 7 radiator, gear box, alternator, engine, kneecaps, crossheads,
bateries, exhaus valves and the fuses; all this parts are thigs
Documentation: It should provide detailed documentation that covers the insurance. Next we have the inside parts, it
for end-users and developers, including user manuals and consist of parts that can be change or can malfuntion with
integration guides. the time passing, for example on this category we have seven
parts, the poweder saves, the direction, the steering rod, the X. P HYSICAL D IAGRAM
zipper, the anti-theft mechanism, the locking mechanism and
the steering wheel. And lastly we have the bottom parts, on A. Diagram
this section we have everything related to the weels of the
car, on this section we have eleven entities, fisrt we have the
brakes, tire rims, leaf springs, suspensions, connecting rods,
stabilizer bars, shock absorbers, steering column, torsion bars
and lastly the wheels.

IX. C LASS DIAGRAM

B. Description
A. Diagram
The pysical diagram explains the process that the system
do physically, on this diagram we will show an example of
it. It starts with the employe entering the system, he enters
the main page, the he need to enter his user and password to
login, after that he enters the main menu with every function,
for this example the employe will sell a car so on the inventoy
checks the car that the client decided to buy, he checks the
stock, the within the Data base he checks the stocks of the car,
after the employe and the client have come to an agreement
of what car has been sold then it comes the insurance, the
employe tells the client the options of insurance he can buy,
then he gernerates the insurances, making a discharge in the
system for traking the insurance of the buyer, afther that he
generates the bill he adds a new sales to the data base, lastly
he hands over the keys to the client.

B. Description
XI. U SE C ASE D IAGRAM
Dealership: Represents the dealership itself and contains key
components such as inventory, sales, insurance, finance, and A. Diagram
employees. It is the main entry point for interacting with the
dealership system. Inventory: Manages the availability of cars
and auto parts in the dealership’s inventory. It has methods for
adding and removing cars, managing stock, and listing avail-
able cars and auto parts. Car: Represents an automobile with
attributes such as brand, model, year, price, and engine type.
Stock: Manages the stock of cars in the inventory and allows
for updating the available quantity. User: Represents the users
who interact with the system and manages functions such as
login and registration. Session: Represents active user sessions,
recording the start and end dates of the session. Employees:
Manages information about dealership employees and allows
for adding and removing employees, as well as listing them.
Insurance: Administers the available types of insurance and
calculates the cost of insurance for cars. Sales: Manages car
sales, records sales transactions, and calculates profits. Sale:
Represents a specific car sale with details such as the sold car,
the customer, the sale price, and the date. Finances: Manages
financial transactions and calculates income, expenses, and
profits for the dealership. FinancialTransaction: Represents
a financial transaction with details such as the transaction
type, amount, and date. AutoPart: Represents auto parts with
attributes such as name, price, and quantity in stock. Menu:
Manages a menu with options to interact with the system.
B. Description An object that manages car sales, including sales records
On this side, the use case diagram we’ll se that both, the and profit calculations. Multiple objects of this class can
Admin and the Employee would be able to sign up, and log represent different sales transactions. Sale: Represents a spe-
in. Then when any client for any situation arrives to the store, cific car sale with details like the sold car, customer name,
the employee would be able to show all the stock that the sale price, and sale date. Multiple objects of this class can
client ask for, then if the client want to buy anything from exist for different recorded sales. Finances: An object that
the stock, the employee first need to registry the customer in manages financial transactions, including transaction records
the data base, then the salesman will mark it as sold. Then and financial calculations. Multiple objects of this class can
in the administraror side, he would be able to see and modify represent different financial transactions. FinancialTransaction:
anything from the stock, and see all the sales. Represents a specific financial transaction with attributes like
”type” for the transaction type, ”amount” for the amount,
XII. O BJECT D IAGRAM and ”date” for the transaction date. AutoPart: Represents an
auto part with attributes like ”name,” ”price,” and ”quantity.”
A. Diagram
In the object diagram, you could have objects of this class
representing different available auto parts. Menu: An object
representing the system’s menu with options for interacting
with the system. It can contain attributes like ”options” that
store a list of available options.

XIII. C OMPONENT D IAGRAM

A. Diagram

B. Description
Dealership: It’s an object representing the dealership itself. B. Description
In this context, it acts as the primary entry point to interact As shown, the activity to be carried out is the purchase of a
with the dealership system. Inventory: An object representing spare part for an automobile. First, the customer requests the
inventory management in the dealership. It contains attributes necessary part, in this case, the brakes. A request is made to the
like ”availableCars,” ”availableAutoParts,” and ”stock,” which system to check the inventory. The required part is searched for
store lists of available cars, available auto parts, and stock in the lower parts section, and the needed spare part is found.
records, respectively. Car: Represents a specific car with Then, the payment details are processed, a bill is generated,
attributes like ”brand,” ”model,” ”year,” ”price,” and ”engine- and the spare part is delivered to the customer.
Type.” In the object diagram, you could have multiple objects
of this class, each representing a different car in the inventory.
XIV. S TATE D IAGRAM
Stock: Represents the stock of a specific car in the inventory,
with attributes ”car” for the associated car and ”quantity” for A. Diagram
the available quantity. Multiple objects of this class can exist
for different cars in stock. User: An object representing a user
interacting with the system. It has attributes like ”username”
and ”password” and is used to manage login and registration
functions. Session: Represents an active user session with
attributes like ”user” for the associated user, ”startDate,” and
”endDate” to record the start and end times of the session.
Employees: An object that contains a list of dealership em-
ployees. It can contain multiple objects of the ”Employee”
class to represent dealership employees. Insurance: Represents
insurance management in the dealership, including available
insurance types. In the object diagram, you could have objects
of this class representing available insurance types. Sales:
B. Description XVI. D EVELOPMENT L OG -S ECOND P ROJECT P ROGRESS
A. Log In
This diagram depicts different states involved in the process
of purchasing a vehicle. We begin with the purchase request,
initiating the vehicle search state. A vehicle is selected,
concluding the vehicle selected state. Alongside this, two
states are entered: model selection and vehicle characteristics
confirmed. With the latter, the vehicle selection along with
its characteristics is completed. It proceeds to the negotiation
state, where insurance is offered. The insurance is contracted,
and we move on to the payment state. Payment is confirmed,
and customer information is gathered. Subsequently, the data
is stored, and the vehicle is delivered to the customer.

XV. C OLABORATION D IAGRAM

-Achievement: Creation of a log in screen

A. Diagram -Description Creation of a safe login interface. Integration
with a user database for authentication. Application of security
measures, such as password encryption.
B. Menu

-Achievement: Create a screen menu that allow the user

access among all the interface.
-Description Create a central interface from other screensto be
accessed. Incorporate an intuitive icons for easy navigation.
B. Description Implementation of a logic to direct the different sections of
the system.

For this diagram the activity to be carried out in this case the C. Spare Parts
purchase of a car is described step by step, mainly we need the
author in this case the client who wants to buy a car, after this
the client all the characteristics that his automobile must have
such as the model, color, engine, transmission among other
characteristics, we move on to the negotiation where the final
purchase price is discussed and where insurance is suggested
followed by this when contracting insurance you can select the
type of insurance that If desired or depending on your need,
completed here the purchase is completed and processed to
save the customer’s information and ends with the customer
acquiring their car. -Achievement: Implementation of the spare parts screen
-Description Develop of an interface to show available spare G. Data Base
parts with the integration of the spare parts inventory database.
Including details on compatibility with car models.

D. Car List

-Achievement: Implementation of the screen that we will be

showing up the list of all the cars.
-Description Design of an attractive visual interface that
shows available cars. Integrating inventory database to display
features and details. Implementation of filters to facilitate the
search for cars.

E. Car Sale

-Achievement: Performing extensive testing on the database.

-Description Verification of query efficiency in simulated
-Achievement: Creation of the interface that allows the user loading environments. Identification and correction of
to create all the papper work to make a succsesfull purchase. possible bottlenecks and performance errors. Implementation
-Description Development of an interface to manage of indexes to improve data access speed.
sales transactions. Integration with the database to update
inventory after a sale. Inclusion of confirmation functions and H. Possible Incidents and Solutions
transaction details. Errors in updating inventory after a sale.
Reviewed and corrected database update queries to ensure
F. Price Previe accuracy of sales transactions.
I. Next Steps
-Continuous improvement of the user interface.
-Implementation of additional functionalities, such as customer
management and tracking of spare parts orders.
-Optimization of overall system performance.

-Achievement: Creation of the interface that allows the user

to simulate the purchase to se the price before buying any
car.
-Description Design of an intuitive interface to calculate car
quotes. Integration with the car catalog and price database.
Extensive testing to ensure quote accuracy.