Object Oriented Programming Project

On
Audi Ticket Booking System
By

Name: ID:
Dhruv Shrimali 2021A7PS0008P
Madhav Nath Khanna 2020B4A71325P
Sourabh Bhandari 2021A7PS2412P
Siripuram Surya 2020B2A71406P

Course- CS F213

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE, PILANI

1
 Anti-Plagiarism Statement

We the members of the group assure you that the work which is
presented is completely done by us and have not taken any type of code
from any sources and was coded by us from scratch. We may have taken
some inspiration but we guarantee that we have written the code in our
own way.

We adhere to the no plagiarism policy and understand the consequences

of the violation, and in case of any type of plagiarism, we will be fully
held responsible for it and will be dealt with it accordingly.

Dhruv Shrimali 2021A7PS0008P

Sourabh Bhandari 2021A7PS2412P

Madhav Nath Gupta 2020B4A71325P

Siripuram Surya 2020B2A71406P

2
 Index
Title Page No.

Title and Team members 1

Anti-Plagiarism Statement 2
Index 3
Contributions of the Members 4
Design Pattern 5
Analysis of Code according to SOLID Principles 6
UML Diagrams for the code 8

3
 Contributions of the Team Members

Name Contributions Signature

Implemented multithreading
Dhruv
Shrimali
Implemented Admin,
Sourabh Booking, Event,
Bhandari Savable, Student, User,
Auditorium,
Exceptions(Backend)
Implemented
Madhav AddEvent,AdminLogin,
Nath AdminScreen,ChangeDetails,
Gupta EventBooking,LogIn,
Main,PreviousBooking,
RegisterScreen,UserScreen
(Frontend)
Designed Project Structure,
Siripura Made UML and
m Surya Documentation.

4
 Design Pattern

 The design pattern followed in this project is Observer

pattern. This is to have a one to many dependency between
objects so that when one object changes state, all its
dependendents are notified and updated accordingly.

 Observer Design pattern is useful when you are interested in

the state of an object and want to get notified whenever there
is any change.

 For example, Student has List<Booking> as it’s member,

and each Booking has List<Seat> and Event as it’s member.
Now if we change the state of say Event, Student is
automatically notified about the change.

 This pattern makes it very convenient to save and retrieve

data.

 We didn’t know about this design pattern at the time of

coding this project, but after completing the coding part, we
found out that this design pattern is very well demonstrated
by our project!

5
Analysis of Code with respect to SOLID principles
1. Single Responsibility Principle:
a. The single responsibility principle states that a class should do
one thing and therefore it should have only a single reason to
change.
b. The code has been designed considering this principle. Each
class has a very specific function.
c. User class deals specifically with login, Auditorium class
strictly maintains the seat matrix, Booking class strictly deals
with the bookings, Student class maintains all it’s bookings,
and so on.
2. Open Closed Principle
a. The open closed principle requires that classes should be open
for extension and closed for modification.
b. Modification means changing the code of an existing class,
and extension means adding new functionality.
c. This is achieved in our project with the use of interfaces.
d. After completing the initial stage of project we realized that all
data is lost once we close the terminal. To counter this, we
added a custom Savable interface in our project. For all the
classes implementing Savable interface, the objects are saved
when the program is closed. In implementing this, we did not
have to change our current class. This could not have been
possible if not for this principle.
3. Liskov Substitution Principle
a. The Liskov Substitution Principle states that subclasses should
be substitute for their base classes.
6
 b. Both Student and Admin inherit the User class, and we use
User class objects wherever both Student and Admin class
objects could have been used.
4. Interface Segregation Principle
a. The principle states that many client-specific interfaces are
better than one general-purpose interface.
b. In our project we have to mainly deal with the Runnable
interface and Savable interface(custom).
c. Making this Savable interface specifically for objects to be
saved on disk, ensures that this principle is followed.
5. Dependency Inversion Principle
a. The Dependency Inversion principle states that our classes
should depend upon interfaces or abstract classes instead of
concrete classes and functions.
b. Savable interface ensures this principle to some extent, but to
be frank, the project doesn’t completely follow this principle.

7
Uml Diagrams

8
9
10
The link for videos of explanation of code:
(Please
https://drive.google.com/drive/folders/1B2rRRZhKm_1SHlxxkv5ww6p3AI2l7kR-?usp=sharing
copy paste the link in your browser if hyperlink is not working).

The GitHub repo of code:

https://github.com/SaurabhRBhandari/Audi-Ticket-Booking-System/tree/main

11