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 . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . 3 XVI-F Price Previe . . . . . . . . . . . . . . . 7
VI-F Functional Requierment 6 . . . . . . . 3 XVI-G Data Base . . . . . . . . . . . . . . . . 7
XVI-H Possible Incidents and Solutions . . . . 7
VI-G Functional Requierment 7 . . . . . . . . 3
XVI-I Next Steps . . . . . . . . . . . . . . . . 8
VII Non-Functional Requirements 3
XVII Log, Incidents and solutions 8
VII-A Non Functional Requierment 1 . . . . . 3
XVII-A Day 1 . . . . . . . . . . . . . . . . . . 8
VII-B Non functional Requierment 2 . . . . . 3 XVII-B Day2-4 . . . . . . . . . . . . . . . . . . 8
VII-C Non functional Requierment 3 . . . . . 3 XVII-C Day 5-7 . . . . . . . . . . . . . . . . . 8
VII-D Non functional Requierment 4 . . . . . 3 XVII-D Day 8-14 . . . . . . . . . . . . . . . . . 8
VII-E Non functional Requierment 5 . . . . . 3 XVII-E Day 15-17 . . . . . . . . . . . . . . . . 8
VII-F Non functional Requierment 6 . . . . . 3 XVII-F Day 17-23 . . . . . . . . . . . . . . . . 8
VII-G Non functional Requierment 7 . . . . . 3 XVII-G Day 23-27 . . . . . . . . . . . . . . . . 8
XVII-H Day 28-31 . . . . . . . . . . . . . . . . 8
VIII ER Diagram 3
VIII-A Diagram . . . . . . . . . . . . . . . . . 3 I. I NTRODUCTION

IX
VIII-B Description . . . . . . . . . . . . . . . .

Class diagram
3

4
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
IX-A Diagram . . . . . . . . . . . . . . . . . 4 requirements of the software we will develop throughout
IX-B Description . . . . . . . . . . . . . . . . 4 this course. The software to be presented in this case is an
automotive system that will handle insurance, appointments,
X Physical Diagram 4 spare parts, and car sales.
X-A Diagram . . . . . . . . . . . . . . . . . 4
X-B Description . . . . . . . . . . . . . . . . 4 A. Purpose
The purpose of this software is to distribute requested spare
XI Use Case Diagram 4 parts, schedule appointments, offer insurance to customers,
XI-A Diagram . . . . . . . . . . . . . . . . . 4 and, in general, handle vehicle sales, all registered in the
XI-B Description . . . . . . . . . . . . . . . . 5 database for control and management.
B. Scope • Development Methodologies: An agile methodology,
• Efficiency in Inventory Management: Ensuring an up- such as Scrum, will be adopted for software development,
dated and optimized inventory to guarantee spare parts with regular iterations and reviews.
availability at all times, avoiding losses due to excessive IV. A SSUMPTIONS AND D EPENDENCIES
inventory or out-of-stock situations.
• Insurance Sales: Providing a platform to compare and • Operating System Availability: It is expected that, through
purchase auto insurance, offering detailed information software development, recent versions of the desired
about available options and assisting customers in making operating system will still be predominant in the market.
informed decisions. • Network: The software is planned to have a stable and
• Car Sales: Facilitating the search, viewing, and purchase secure network infrastructure, which is essential for real-
of new and used vehicles, including detailed pricing, time operations.
specifications, and financing options. • Access to Inventory Data: It is assumed that access to a
• Customer Experience: Prioritizing customer satisfaction reliable and up-to-date database of spare parts for vehicles
through effective customer service, technical support, and from different brands and models is available, as this is
seamless purchase processes. essential for enabling parts search and purchase.
• nalytics and Reporting: Collecting and analyzing data • Data Security: It is assumed that robust data security
on user interaction with the platform to gain valuable measures have been implemented to protect users’ confi-
insights into customer behavior, marketing campaign ef- dential information, such as personal and financial data.
fectiveness, and inventory management. • Marketing Strategy: Relying on an effective marketing
strategy to attract users and generate sales.
C. Overview
V. F ORESEEABLE S YSTEM E VOLUTION
This system is being developed to be user-friendly and
easy to use, providing a simple interaction with users and • Mobile and Applications: The development of mobile
maintaining constant updates with the database to prevent data applications could be a natural evolution, allowing users
loss. We will showcase an easy-to-understand interface that to access services more conveniently from their mobile
displays the various established options. devices.
• AI Integration and Automation: The incorporation of ar-
II. G ENERAL D ESCRIPTION tificial intelligence and automation could enhance system
A. Product Perspective efficiency. For example, a chatbot or virtual assistant
The dealership’s program will be software designed to could provide online support to users and assist in spare
facilitate the purchase of vehicle parts and vehicles themselves, parts searches.
among the options mentioned earlier. It will be managed • Expansion of Target Market: In addition to individual
through a database that will be constantly updated. This consumers, the system could target vehicle rental com-
software is open to future design or structural improvements. 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
• Programming Language: The application is developed Insurance Comparison: The program should allow users to
exclusively for use within the dealership, so the primary compare different auto insurance options, including coverage,
language to be used will be Python. price, and terms.
• Hardware: The software operates with a manager’s ac-
cess for editing and updating information directly in the C. Functional Requierment 3
database, and for employees who record sales and update Vehicle Listings: It should display detailed listings of
stock quantities to prevent overselling. vehicles for sale, including images, technical specifications,
• Operating System: Efforts will be made to ensure com- and prices.
patibility with various operating systems, but it will be
primarily designed for Windows 10 and later. D. Functional Requierment 4
• Specific Standards: All transactions and the storage of Inventory Management: The system must track spare parts
personal data must comply with data protection regula- and vehicle inventory in real-time, automatically updating
tions such as GDPR and other local privacy laws. when a purchase is made.
E. Functional Requierment 5 VIII. ER D IAGRAM
Payment Integration: It should support various payment A. Diagram
methods, such as credit cards and bank transfers.

F. Functional Requierment 6
Notifications and Reminders: It can send email or text
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. Description
B. Non functional Requierment 2
As we can see, this diagram is masive, non the less its
Security: It must comply with security standards, including comprensible and have an order; We are going to start with
protection against cyberattacks, fraud prevention, and user data the employe, the client and the administrator, all of the can
security. enter the main page of the program, but not everyone can enter
the main menu or the system, for example, the client can only
C. Non functional Requierment 3 see the main page for information, it will not be a program
that can be access from anywhere, it will be only shown for
Scalability: It should be scalable to handle future traffic
make apointments by the employe. The employe can access
and user demand growth.
the login page and access some of the funtions like the stock,
the sales and the insurance, but cant access the modification
D. Non functional Requierment 4 funtions of the program. The admin will have access for every
funtion of the program. Now how the program intract with
Usability: It should be user-friendly with an intuitive inter-
itself, starting from the system, we can interact with the funtion
face for users of all experience levels.
sales, finances, insurances,archive and inventory, Sales only
stores like the names imply, the sales of the department. next
E. Non functional Requierment 5 we have the finances, in it we can store the monthly balance,
Maintainability: It should be easy to maintain and update as well as the income and expenses of the department. Next
with new features and bug fixes. we have the insurance, in the insurance we divide it by two
types of insurance, Normal cover and full cover, like the name
implies, one can only covers minor damages, and the full
F. Non functional Requierment 6
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
radiator, gear box, alternator, engine, kneecaps, crossheads,
G. Non functional Requierment 7
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.
-DataBase incident log: Created the configurations for each
F. Price Previe major section of the database, being the inventory, login and
system.
-Set the configurations for each section to their respective
ports. Realized that we couldn’t put those ports in that number
(21010, 21020, 21030) because they belonged to other ports
later and we decided to change them for other ports (21000,
22000, 23000).
-Set their configurations on those ports and established that
port 21000 will be the mother port, meaning that ports
22000 and 23000 will be dependent on the other port. Then
started partitioning the folders, got an error in a folder called
-Achievement: Creation of the interface that allows the user FinancesIncomesandExpenses, and couldn’t create it because
to simulate the purchase to se the price before buying any it had and so we proceed to deleted the and and continued
car. it. End partitioning the tables into folders without any other
-Description Design of an intuitive interface to calculate car problems. Started the relationship of each table, for example
quotes. Integration with the car catalog and price database. table 21010 has 5 data, now they are all related.
Extensive testing to ensure quote accuracy. -Visual Incident Log
-We looked up how to program in Python together with tkinter. G. Day 23-27
-Created a simple login that will display a success message. Improvements to the Tkinter graphical interface. Visual and
-Redesigned the login so that it had a logo, ghost text in the design adjustments to improve the user experience. Resolu-
text boxes, and when logging in, it opened another window tion of possible incidents in the user interface. Incidence:
with different programming Occasional display errors on the quote screen: Users report
-Modified the password section so that it shows a ”*” instead occasional incorrect data or misplaced interface elements
of characters. appearing on the quote screen. Code debugging and display
-Made a ”base” screen with the base design that we will use bug fixes: Track bug reports closely and fix coding issues that
for the other screens. lead to display errors. Implement additional tests to ensure the
-Adding to this, color, buttons and a small logo in one corner. stability of the quote screen.
-Windows will be updated to save space in the quick quote
part. H. Day 28-31
I. Next Steps Creating Car Catalog Screen with Full Details with Tkinter:
Interface that shows the available cars in a complete and
-Continuous improvement of the user interface. detailed way. Implementation of filters to facilitate the search
-Implementation of additional functionalities, such as customer for cars. Incidence: Challenges in implementing filters in
management and tracking of spare parts orders. the interface: The filters do not work properly, making it
-Optimization of overall system performance. difficult to efficiently search for cars in the catalog. Solution:
XVII. L OG , I NCIDENTS AND SOLUTIONS **Optimization
A. Day 1
Beginning the development of the login system with Tkinter.
Creation of the basic structure for user management. Imple-
mentation of login interface using Tkinter with mock data.
Incident: No incidents
B. Day2-4
Design of the initial database structure in MongoDB: Defi-
nition of collections for users, cars and transactions. Incident:
No incidents
C. Day 5-7
Creation of initial schematics for the car quote and sale
screens with Tkinter. Design of basic quote and sale interfaces
Incident: No incidents
D. Day 8-14
Development of the quote screen with basic functionalities
with Tkinter. Design of an intuitive interface to calculate car
quotes. Incident: Errors when coding on the screen, it took us
time to make connections, we carried out an exhaustive review
of the price data and corrected any inconsistencies.
E. Day 15-17
Initial integration of the car catalog with the Tkinter graph-
ical interface. Showing a basic list of cars from the database
in the Tkinter interface. Incidents: Problems when displaying
images on the main screen
F. Day 17-23
Development of the main menu screen with Tkinter. Cre-
ation of a central interface to access other screens. Incorpora-
tion of intuitive icons for easy navigation. Incidence: Naviga-
tion problems due to confusing interface: Users find it difficult
to navigate between screens due to an unclear interface. User
Interface Review and Redesign: Conduct usability tests with
real users to identify problem points. Make adjustments to
navigation and layout to improve user experience.