PROJECT SYNONPIS

1. Title: Car Company Website

2. Statement of the Problem: This website system will provide a curated, single-window platform for
clients to view, choose, customize, receive quotations, and improve their car purchase experience.
3. Why This Topic: All the existing Auto companies have witnessed high sales even after pricing
crises like Covid-19, followed by a global economic downturn. Along with this, India is the most tech-
savvy nation, thus such interactive websites can enhance the purchase experience.
4. Objective & Scope:
 Objective: To provide a comprehensive online platform for users to explore, select, and
enquire about various car models offered by the company, showcasing detailed information
about each car model.
 Scope: Users can customize their preferences, facilitate test drive and quotation requests, and
provide contact information for further assistance.
5. Methodology: To make this website, I will be following the Spiral Method, so that we can add new
data in every update while the website is live at the same time by planning, analysis, construction,
release, and customer evaluation.

Figure 1 : Spiral Model

1
6. Purpose Architecture: Since this website is dynamic and responsive, it will use Three-Tier
Architecture.
 (i) Presentation-tier:
o Handles the user interface.
o GUI tasks like taking user values like quotation request, test drive form.
 (ii) Application-tier: Also known as logical tier.
o Executes application functionality.
o Communicates with data tier.
o Contains company logo.
 (iii) Data tier:
o Responsible for managing system data.
o Includes databases for customer data.
o Can retrieve and store data.
Requirements
 Web browser to search the web page.
 Stable internet connection.
 PC, laptop, tablets, mobile phones.
 Database, server, programming languages.

8. Contribution to the Society:

It will provide a user-friendly platform for individuals to explore and learn about different car models
and make informed purchasing decisions. This will enhance customer satisfaction, thereby fostering
trust & loyalty.
9. Conclusion:
This website aligns with the company's goal of leveraging technology to enhance customer
engagement and satisfaction. By implementing a robust architecture, this website will serve as a
valuable asset in promoting the company's products and services.

2
 CHAPTER 1: INTRODUCTION

1.1 BACKGROUND:
A modern responsive Car Website system is a great application of UI/UX and GUI design. This type of
website enables its citizens to purchase vehicles. The growing income of a country enables its citizens
to purchase vehicles. This type of interactive website is preferred by customers to improve their
buying experience.

1.2 OBJECTIVE:
 Provide customization option for car interiors.
 Facilitate test drive schedule.
 Raise quotation.
 Allow clients to choose desired dealerships.

1.3 PURPOSE:
The primary purpose of this system is to provide a single-window platform where customers can
select, compare, customize, and purchase cars. It helps the customers to take informed decisions, so
they get value for money.

1.4 APPLICATION:
This kind of a system can be used for any commercial products that have high value and require data
before purchase.

1.5 SCOPE:
To begin with, the scope is restricted for trial usage for students. The scope can be extended when the
system advances.

3
 CHAPTER 2: SURVEY OF TECHNOLOGIES

Front-End Technologies:

1. HTML: Hypertext Markup Language is a standard language for creating webpages. It allows to
input text, images, videos, files for download, etc. It is used to create content and structures like
paragraphs, forms, headings, etc.

2. CSS: Cascading Style Sheet is used to style & layout the webpages, such as headings, paragraphs,
car listings, and forms by including colors, fonts, etc.

3. JavaScript: It is a programming language that allows you to create animated images, dynamic
content updates, and handles user interaction like clicks and inputs.

4. ANGULAR: It is a JavaScript library that lets you build dynamic websites quickly. It has built-in
support for routing. This makes building single-page applications easier.

5. REMIX: Remix is an open-source visual tool for building and deploying web applications. It’s
perfect for creating mobile apps and websites, and allows you to edit the source code of your site
directly in the browser without having to use a text editor. Also, it works perfectly as a backend with
any of the front-end technologies.

Back-End Technologies:

1. PHP: PHP (Hypertext Preprocessor) is a server-side scripting language for web development. It is
used to manage form submissions, session tracking, and interacts with database.

2. Node.js: It is a JavaScript runtime built on Chrome's V8 JavaScript engine. It is used to build

scalable network applications and handle server-side operations and API requests.

4
3. MONGODB:
No SQL source is available for cross-platform document-oriented database. Uses JSON-like
documents with optional schema. It can work with languages like JavaScript, Python, Java, PHP,
Ruby, Perl, etc.It is an open-source relational database management system. It is used to store user
data, customization option, test drive, quotation request. It ensures data integrity and efficient data
retrieval.

(4) RUST: Since 2010, Rust has been recognized for its focus on safety and performance. It features
an effective built-in library, dependency managers, Cargo, and is favoured for its performance quality.

(5) DJANGO: It is a high-level Python web framework designed for rapid development and clean,
pragmatic design. It encourages the use of reusable code, making it efficient for building web
applications.

Why this technology:

I have decided to develop frontend with HTML, CSS, JavaScript, and backend and PHP with Node.js,
MySQL for database. I am opting for these languages because I have been taught these languages till
date.

5
 CHAPTER 3: REQUIREMENT ANALYSIS

3.1 PROBLEM DEFINITION

This car website system is designed to address challenges faced by individuals in selecting their
internal customization choices in cars.
It aims to provide a single-window platform where users will have the opportunity to browse through
their desired cars with options for scheduling test drives, making e-quotations, and most importantly,
make internal customizations like seat fabric, seat colors, floor patterns, heated steering, and car
dealerships.
This system will help the car dealerships to maintain a track of their website's visitors, automate test-
drive scheduling, process requests for customized car models, advertise their upcoming projects
through Google SEO, and auto-generate quotations.

3.2 REQUIREMENT SPECIFICATION

3.2.1 Requirement Gathering:

I have used Google Forms to gather requirements for this project. 4 Responses were recorded for the
purpose of collecting data.

6
7
8
9
10
11
12
3.2.2 Requirement Analysis: Functional Requirements

 Car details: The website should display all the car models of the car showroom with
information like price, model, features, and images.
 Test drive request: Users should be able to request for a test drive using a form to enter details
like preferred time and date, name, contact number, email id, address.
 Customization: Users should be able to choose car features like color, type, seat covers, model
variant.
 Quotation request: Users should be able to request for quotation of any car model.
 Contact details: The website must display the company's contact details like head office
address, showroom address, email, phone, user contact form.
 About us: The website should have a dedicated "about us" page/section to describe the
company's history, mission, client base, services, etc.

3.2.3 Non-Functional Requirements:

 Usability: The website interface should be user-friendly and should have easy navigation.

13
  Security: The user data submitted through forms should be stored securely (for securing data,
website should have HTTPS).
 Availability: The website should be running most of the times with minimal downtime.
 Maintainability: It should follow a spiral model to make updates, and the codes should be
well-documented and stored.

3.2.2 Requirement Analysis: Functional Requirements

 Car details: The website should display all the car models of the car showroom with
information like price, model, features, and images.
 Test drive request: Users should be able to request for a test drive using a form to enter details
like preferred time and date, name, contact number, email id, address.
 Customization: Users should be able to choose car features like color, type, seat covers, model
variant.
 Quotation request: Users should be able to request for quotation of any car model.
 Contact details: The website must display the company's contact details like head office
address, showroom address, email, phone, user contact form.
 About us: The website should have a dedicated "about us" page/section to describe the
company's history, mission, client base, services, etc.

3.2.3 Non-Functional Requirements:

 Usability: The website interface should be user-friendly and should have easy navigation.
 Security: The user data submitted through forms should be stored securely (for securing data,
website should have HTTPS).
 Availability: The website should be running most of the times with minimal downtime.
 Maintainability: It should follow a spiral model to make updates, and the codes should be
well-documented and stored.

System Requirements

14
1. REGISTER:
 Description: User can create an account.
 Input: First name, last name, username, email, password, & confirmation of password.
 Source: User
 Destination: Data stored in database
 Pre-Condition: User should have website URL.
 Post-Condition: Redirected to login page if registration is successful.
 Exception: Show error message if all fields are not filled.

2. LOGIN:
 Description: User can login to their account.
 Input: Username, password
 Source: User
 Destination: Data stored in the database
 Pre-condition: User should have website URL.
 Post-condition: Redirected to home page if credentials match.
 Exception: Error message if credentials don't match.

3. CAR LISTING:
 Description: User can view all the car models
 Input: No input after opening for the first time.
 Source: Website database
 Destination: User's browser
 Pre-condition: User should have website URL.
 Post-condition: Car listings are displayed on the user screen.
 Exception: Error message if car listing does not load.

4. VIEW CAR DETAILS:

15
  Description: User can view details of a specific model.
 Input: Car model selection by clicking on it
 Source: Website database
 Destination: User's browser
 Pre-condition: Car listings should load.
 Post-condition: Information of the model is displayed.
 Exception: Error message if car details does not load.

5. CAR CUSTOMIZATION:
 Description: Users can customize features like color, interiors, etc.
 Input: Customization selection
 Source: User
 Destination: Website database (temporary storage)
 Pre-condition: User needs to select a model.
 Post-condition: All customization options are displayed.
 Exception: Error message if customization option doesn't load.

6. TEST DRIVE REQUEST:

 Description: Users can apply for test drive requests.
 Input: User details like name, contact information, preferred date & time.
 Source: User
 Destination: Website database
 Pre-condition: User needs to select a model.
 Post-condition: Request for test drive is stored and a confirmation message appears.
 Exception: Error message if form is incomplete.

7. QUOTATION REQUEST:
 Description: User can apply for quotation request.
16
  Input: User details & car model
 Source: User
 Destination: Website database
 Pre-Condition: User needs to select a model.
 Post-Condition: Request for quotation is stored and a confirmation message appears.
 Exception: Error message if form is incomplete.

8. CONTACT US:
 Description: User can send inquiry via contact form.
 Input: User name, email id, message, contact number, etc.
 Source: User
 Destination: Website database (email received to the company)
 Pre-Condition: User should have website URL.
 Post-Condition: Confirmation message is shown.
 Exception: Error message if form is incomplete.

9. ABOUT US:
 Description: User can view company information.
 Input: No user input
 Source: Website database
 Destination: User's browser
 Pre-Condition: User should have website URL
 Post-Condition: Company information is displayed.
 Exception: Error message if information doesn't load.

17
 CHAPTER 4: SYSTEM DESIGN

4.1 Module diagram

Module diagram is a diagram which is used for showing the allocation of classes and objects to module
in the physical design of a system. Module Diagram indicates the partitioning of the system
architecture. Through this diagram, it is possible to understand the general physical architecture of a
system. The two essential elements of a module diagram are modules and their dependencies.

Figure4. 1 Module Diagram

18
 Module Diagram for the Car Website System
The module diagram represents the structure of the system, showing how different modules interact with each
other. For the Car website System, we can break it down into several key modules:

1) USER MANAGEMENT MODULE

2) CAR MANAGEMENT MODULE
3) TEST DRIVE MANAGEMENT MODULE
4) QUOTATION MANAGEMENT MODULE
5) CONTACT MANAGEMENT MODULE
6) ADMIN MODULE

DESCRIPTION:
1) USER MANAGEMENT MODULE:
 Handle all user account operations.
 Manages login.
 Handle user registration.
2) CAR MANAGEMENT MODULE:
 Manages all car-related operations.
 Handles all car listings.
 Displays details/description of cars.
 Integrates all car customization options.
3) TEST DRIVE MANAGEMENT MODULE:
 It manages list drive requests of clients.
 Manages the status of test drive.
 Tracks the schedule of test drive.
4) QUOTATION MANAGEMENT MODULE:
 Handles car quotation requests of users.
 Integrates customization in quotations.
 Tracks the status of quotation requests.

19
5) CONTACT MANAGEMENT MODULE:
 Manages user inquiry.
 Tracks inquiry status.
6) ADMIN MODULE:
 All administrative functionalities to manage all the other modules.

4.2 Entity Relationship Diagram

An Entity-Relationship Diagram is a visual representation used to model the structure of a
database. It illustrates the relationships between different entities, whichrepresent real-world
objects, concepts, or information within the database system. ER diagrams consist of entities,
attributes which are the properties of those entities,relationships which are the connections
between those entities, and cardinality among those entities. ER diagrams are essential tools for
database design, helping developers and stakeholders understand the logical organization of data,
identifying key relationships, and ensuring the proper implementation of a database schema. By
providing a clear and intuitive overview, ER diagrams play a crucial role in improving
communication and ensuring the accuracy of database systems in various domains, suchas
business, software development, and data management. ER model becomes an abstract data
model that defines a data or information structure which can be implemented typically in a
relational database.

Diagram Notations:
NOTATION SYMBOL DESCRIPTION

Represents a real-world object

Entity or concept (e.g., Person,
Rectangle Order).

An entity that depends on

Weak Entity
another entity for its existence.
Double Rectangle

20
NOTATION SYMBOL DESCRIPTION

Represents a property of an
Attribute
entity (e.g., Name, Age).
Oval

An attribute that is calculated

Derived Attribute
from other attributes.
Dashed Oval

An attribute that can have

Multi-valued Attribute multiple values (e.g., Phone
Double Oval Numbers).

Uniquely identifies each entity

Primary Key Underlined Attribute
instance.

Represents a connection
Relationship between entities (e.g.,
"enrolls").
Diamond

Connects entities to
Line Line relationships, showing
interactions.

Single Line
Indicates a one-to-one
One-to-One
relationship between entities.

Line with Crow's Foot

Indicates one entity relates to
One-to-Many
multiple instances of another.

21
NOTATION SYMBOL DESCRIPTION

Crow's Feet on Both Ends

Indicates multiple instances of
Many-to-Many one entity can relate to multiple
instances of another.

Double Line Indicates all instances of an

Total Participation entity are involved in a
relationship.

Indicates only some instances

Partial Participation Single Line
are involved in a relationship.

Triangle Represents inheritance between

Generalization/Specialization
entities.

Indicates that a relationship is

Aggregation Dashed Rectangle
treated as a higher-level entity.

Table 4.1 Entity Relationship symbols

Entities description and Attributes for Car website system:

1. User
o Description: Represents a user who interacts with the website, either as a guest or
a registered member.
o Attributes:
 user_id (Primary Key): Unique identifier for the user.
 first_name: First name of the user.
 last_name: Last name of the user.
 email: Email address of the user.
 username: Chosen username for login.
 password: Password for account access.
 phone_number: Contact phone number.
 address: Physical address of the user.

22
  registration_date: Date when the user registered on the website.
2. Car
o Description: Represents a car model available for viewing and customization.
o Attributes:
 car_id (Primary Key): Unique identifier for the car.
 model_name: Name of the car model.
 manufacturer: Manufacturer of the car.
 price: Base price of the car.
 description: Detailed description of the car.
 image_url: URL to the car's image.
 video_url: URL to the car's video.
 available_colors: List of available colors for the car.
 specifications: Specifications of the car (e.g., engine type, horsepower).
3. Customization
o Description: Represents a customization option for a car.
o Attributes:
 customization_id (Primary Key): Unique identifier for the customization.
 car_id (Foreign Key): Identifier of the car model being customized.
 color: Selected color for the car.
 interior_features: Selected interior features.
 accessories: Additional accessories selected.
4. Test Drive Request
o Description: Represents a user's request to test drive a car.
o Attributes:
 test_drive_id (Primary Key): Unique identifier for the test drive request.
 user_id (Foreign Key): Identifier of the user requesting the test drive.
 car_id (Foreign Key): Identifier of the car to be test-driven.
 preferred_date: Preferred date for the test drive.
23
  preferred_time: Preferred time for the test drive.
 status: Status of the test drive request (e.g., pending, approved, completed).
5. Quotation Request
o Description: Represents a user's request for a quotation for a car.
o Attributes:
 quotation_id (Primary Key): Unique identifier for the quotation request.
 user_id (Foreign Key): Identifier of the user requesting the quotation.
 car_id (Foreign Key): Identifier of the car for which the quotation is requested.
 customization_id (Foreign Key): Identifier of the customization options
selected.
 status: Status of the quotation request (e.g., pending, provided).
6. Contact Inquiry
o Description: Represents a message or inquiry sent by a user through the contact
form.
o Attributes:
 inquiry_id (Primary Key): Unique identifier for the contact inquiry.
 user_id (Foreign Key): Identifier of the user sending the inquiry.
 message: The content of the user's message.
 timestamp: Date and time when the inquiry was sent.
7. Admin
o Description: Represents an administrator who manages the website.
o Attributes:
 admin_id (Primary Key): Unique identifier for the admin.
 username: Admin's username.
 password: Admin's password.
 email: Admin's email address.
ENTITIES & ATTRIBUTES
(A) User: A user who interacts with the website

24
  user_id: Unique user identifier (Primary key) [integer]
 name: User's first name [string]
 last_name: User's last name [string]
 email: User's email id [string] (email format)
 username: Account username [string]
 password: Account password [string]
 contact_number: User's contact number [string]
 address: User's residential address [string]
 registration: Date of registration [Datetime]
(B) Car: The listed car model
 car_id: Unique car identifier (Primary key) [integer-auto]
 model: Name of car model [string]
 description: Car's specification [text]
 image: Image of car [string in URL form]
 video: Video of car [string in URL form]
 colors: List of colors available [array of string]
 price: Price of car [decimal]
(C) Customization: The available custom features of cars
 customization_id: Unique primary customization data identifier (Primary key) [string]
 car_id: Car model identifier (Foreign key) [integer]
(D) Test Drive Request: The car's test drive request of a user
 td_id: Unique test drive request identifier (Primary key) [integer]
 user_id: User identifier (Foreign key) [integer]
 car_id: Test drive car identifier [integer]
 td_date: Preferred date for test drive [date]
 td_time: Preferred time for test drive [time]
 status: Test drive request status (e.g., booked, completed, pending) [string]
(E) Quotation Request: User's quotation request for a car
25
  qt_id: Unique quotation request identifier (Primary key) [integer-auto]
 user_id: User identifier for requesting quotation (Foreign key) [integer]
 car_id: Car identifier for which quotation is requested (Foreign key) [integer]
 customization_id: Identifier for selected customization options (Foreign key) [integer]
 qt_status: Status of quotation request (e.g., accepted, rejected) [string]
(F) Contact Enquiry: Message sent by user via contact form
 inquiry_id: Unique contact inquiry identifier (Primary key) [integer-auto]
 user_id: Identifier of user sending enquiry (Foreign key) [integer]
 message: The content of the message [text]
 time: Date and time of enquiry [datetime]
(G) Admin: The administrator who manages the website
 admin_id: Unique identifier for the admin (Primary key) [integer-auto]
 username: Admin's username [string]
 apassword: Admin's account password [string]
 aemail: Admin's email id [string (email format)]

Relationships:
 User to Test Drive Request: One-to-Many (A user can make multiple test drive requests).
 User to Quotation Request: One-to-Many (A user can request multiple quotations).
 User to Contact Inquiry: One-to-Many (A user can send multiple inquiries).
 Car to Customization: One-to-Many (A car can have multiple customization options).
 Car to Test Drive Request: One-to-Many (A car can be requested for test drives by multiple
users).
 Car to Quotation Request: One-to-Many (A car can be requested for quotations by multiple
users).
 Customization to Quotation Request: One-to-One (A customization is linked to a specific
quotation request).

26
 FIGURE 4.2 ENTITY RELATIONSHIP DIAGRAM

4.3 Schema Diagram

A database schema is the skeleton structure that represents the logical view of theentire
database. It defines how the data is organized and how the relations among

27
them are associated. It formulates all the constraints that are to be applied on the data.

Diagram Notations:

Name Symbol Description

Table A table is a collection of related data held in table
format withina database.

Relation In a relational database system, a one-to-one table

relationship links two tables based on a Primary
Key column in the child which is also a Foreign
Key referencing the Primary Key of theparent
table row. Therefore, we can say that the child
table share the Primary Key with the parent table.
Table 4.2 Schema diagram symbols

28
FIGURE 4.3 SCHEMA DIAGRAM

29
4.4 Data Flow Diagrams

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows
within a system. A neat and clear DFD can depict the right amount of the system
requirementgraphically. It can be manual, automated, or a combination of both.

It shows how data enters and leaves the system, what changes the information, and where
datais stored.

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may
beused as a communication tool between a system analyst and any person who plays a part
in theorder that acts as a starting point for redesigning a system. The DFD is also called as
a data flow graph or bubble chart.

Symbol Name Function

Data Flow Used to connect processes to each other, to sources or
sinks. The arrowhead indicates the direction of data
flow.
Process Performs some transformation of input data to yield
output data.

Source of A source of system inputs or a sink of system outputs.

Sink(External
Entity)
Data Store A repository of data. The arrowheads indicate net
inputs and net outputs to the store.

Table 4.3: Data Flow Diagram

symbols

30
FIGURE 4.4 CONTEXT LEVEL DATA FLOW DIAGRAM

31
FIGURE 4.5 DATA FLOW DIAGRAM LEVEL 1

32
FIGURE 4.6 DATA FLOW DIAGRAM LEVEL 2(Car, Test drive and Admin management)
33
4.5 Use Case Diagram
A use case diagram at its simplest is a representation of a user's interaction with the system that
shows the relationship between the user and the different use cases in which the user is involved.
A use case diagram can identify the different types of users of a system and the different use cases
and will often be accompanied by other types of diagrams as well. The use cases are represented

by either circles or ellipses.

Symbols Reference: https://www.lucidchart.com/

Actor Actor represents a user or

another system that will
interact with the system you
are modelling
Use case A use case is an external view
of the system that represents
some action the user might
perform in order to complete
a task.
Associations Association between use
cases.

Include Relationship Include relationship between

the use cases

Table 4.4 Use Case Diagram Symbols

34
 Use Case Diagram for Car Website System
Below is a description of the use case diagram for the Car website System, which includes two main
actors: Agent and Admin.

DESCRIPTION OF USE CASE

1) REGISTER:
 SUMMARY: Allows user to register on the website.
 ACTORS: User
 DESCRIPTION: User provides personal credentials.
 PRE CONDITION: Internet availability
 POST CONDITION: User account created successfully.
 EXCEPTION: Registration fails due to invalid/incomplete info.
2) LOGIN:
 SUMMARY: Allows users to login to their account.
 ACTORS: User
 DESCRIPTION: User provides credentials to login.
 PRE: User must be registered.
 POST: User login is successful.
 EXCEPTION: Fails if credentials are incorrect.
3) BROWSE CAR:
 SUMMARY: Allows user to search all the listed cars.
 ACTORS: User
 DESCRIPTION: User can search their desired car.
 PRE: The car is listed on the browser.
 POST: The desired car model appears.
 EXCEPTION: The model is out of stock or discontinued.
4) CUSTOMIZE:
 SUMMARY: Allows user to customize the car's features.
35
  ACTORS: User
 DESCRIPTION: Allows user to choose color, interior seat covers, steering handles, dash cam,
car cover, alloy wheel base.
8) MANAGE USER:
 SUMMARY: Allows admins to track users.
 ACTOR: Admin
 DESCRIPTION: It can access the account of users in the database.
 PRE: Admin must be registered.
 POST: Successfully access user details.
 EXCEPTION: Cannot find user details because the account does not exist.
9) ADD CAR LISTING:
 SUMMARY: Allows admin to list new cars.
 ACTOR: Admin
 DESCRIPTION: It is used to update the list by adding/deleting car models.
 PRE: Admin should have access.
 POST: The list of cars is successfully updated.
 EXCEPTION: Error in the code of car list.
10) MANAGE TEST DRIVE REQUEST:
 SUMMARY: Allows admin to manage test drive schedules.
 ACTOR: Admin
 DESCRIPTION: It is used to accept/decline test drive scheduling requests.
 PRE: A request is raised by any user.
 POST: The test drive is scheduled.
 EXCEPTION: The request cannot be responded to due to unavailability of slots.

36
FIGURE 4.9 USE CASE DIAGRAM

37
 SCENARIO
1) REGISTRATION:
 User opens the website.
 Home page of the website appears.
 Registration option is displayed.
 User enters details like name, mobile, email, address.
 System validates the details.
 The details are saved & a new account is created.
 If there is an error, an error message occurs.
2) LOGIN:
 User opens the website.
 User selects the login option.
 User enters login details like username, password.
 If the account exists, login is successful.
 If the account is not found, an error message appears.
 The user is logged in to the home page.
3) BROWSE CAR:
 User opens the website and lands on the home page.
 The browse option has to be selected.
 The page shows all the listed cars.
 The list shows model name, model id, description, base price.
 If the internet connection is stable, all the data is shown.
4) CUSTOMIZATION:
 User opens the car list.
 User has to select the desired model.
 The complete data sheet of that car model is displayed.
 The customization options for the model appear.
 The options like interiors & exteriors for customization open up.
38
  The user has to choose the desired options.
5) TEST DRIVE REQUEST:
 User has to select a car.
 User can add the desired customization options.
 User has to confirm his/her selection.
 The selected option is saved in the user's account.
 On the home screen, "test drive" option is available.
 On selecting "test drive," options for date & time appear.
 User selects a preferable date and time.
 The request has to be submitted, and a request ID generates.
6) QUOTATION REQUEST:
 The user has to select a car.
 The user has to select the customization options if any.
 On the screen, the quotation option is generated and available.
 On selecting "quotation," the quotation request is generated.
 It captures all user details, car details, and customization details.
7) CONTACT INQUIRY:
 On the home screen, the "contact us" option is available.
 On selecting it, a subpage opens.
 It contains information about the car company.
 It shows data like company address, mail id, phone number.
 A section for user input appears.
 The user can write a message of up to 200 characters.
 This contains a submit button.
 A contact inquiry ID is generated.

39
4.6 Sequence Diagram
A sequence diagram in a Unified Modelling Language (UML) is a kind of interaction diagram that
shows how processes operate with one another and in what order. A sequence diagram shows
object interactions arranged in time sequence. It depicts the objects and classes involved in the
scenario and the sequence of messages exchanged between the objects needed to carry out the
functionality of the scenario. Sequence diagrams typically are associated with use case realizations
in the Logical View of the system under development.

Symbol reference: https://www.lucidchart.com/

Name Symbol Description

Synchronous Message Aninstantaneous
communication between
objects that conveys
information, with the
expectation that an action
will be initiated as a result.
Activation Box The period during which an
object is performing an
action.
Object An object that is created,
performs actions, and/or is
destroyed during the lifeline
Table 4.6 Sequence Diagram Symbols

40
 FIGURE 4.10 REGISTER

FIGURE 4.11 BROWSE CAR

41
FIGURE 4.12 CUSTOMIZATION

FIGURE 4.13 QUOTATION

42
FIGURE 4.14 TEST DRIVE

43
 4.7 Activity diagram
Activity diagram is another important diagram in UML to describe the dynamic
aspects of the system.
Activity diagram is basically a flowchart to represent the flow from one activity to another
activity.
The activity can be described as an operation of the system. The control flow is drawn from one
operation to another.
This flow can be sequential, branched, or concurrent. Activity diagrams deal with all type of
flow control by using different elements such as fork, join, etc.
Symbol reference: https://www.lucidchart.com/

Table 4.6 Activity Diagram Symbols

44
FIGURE 4.15 ACTIVITY DIAGRAM
45