TravelWithMe

1.Introduction
2.Diagrams…
2.1. Flight use case diagram
2.2. Flight sequence diagram
2.3. Flight activity diagram
2.4. Flight use case description
2.5. Hotel use case diagram
2.6. Hotel sequence diagram
2.7. Hotel Activity diagram
2.8. Hotel use case description
2.9. Sales use case diagram
2.10. Sales sequence diagram
2.11. Sales Activity diagram
2.12. Sales use case description
2.13. Domain Class Diagram
2.14. Design class diagram.
2.15. First Cut Design class diagram.
2.16. CRC Card.
2.17. Communication Diagram.
2.18. Multi-Layer Sequence diagram.
2.19. Component Diagram.
2.20. Registration use case diagram.
3. Electronic Internal output Reports
3.1. Flight internal report
3.2. Car rental internal report
4. Electronic External output Reports
4.1. Flight external report
4.2. Car rental external report
5.Design Patterns
5.1. Singleton Design Pattern
5.2. Abstract Factory Design Pattern
5.3. Adaptor Design Pattern
5.4. Bridge Design Pattern
5.5. Flyweight Design Pattern
5.6. Iterator Design Pattern
5.7. Mediator Design Pattern
5.8. Strategy Design Pattern
5.9. Observer Design Pattern
6. User Interface.

1.Introduction
In the contemporary era of digital convenience, the travel
industry has witnessed a paradigm shift towards online
reservation systems, catering to the evolving needs and
preferences of modern travelers. In this context, TravelWithMe
emerges as a frontrunner, revolutionizing the travel experience
through its innovative Online Travel Reservation System (TRS).
Formerly a traditional tour operator website, TravelWithMe has
embraced digital transformation to provide a seamless platform
for travelers to book flights, hotels, and car rentals, while also
prioritizing personalized user profiles and efficient account
management. This report delves into the intricacies of
TravelWithMe's TRS, exploring its core functionalities, customer-
centric approach, and the underlying processes that drive its
success in delivering unparalleled convenience and value to
travelers worldwide. From price quoting to order validation, this
report sheds light on details of diagrams, details of electronic
reports and details of UI.

2.Diagrams:
2.1. Flight use case diagram

At first customer login to the website and start flight booking

process through selecting some details about his trip, then he will
search for available offers where the system is the one that
display these offers.
Customer continue booking process and enter payment
information then the system checks this information.

2.2.Flight sequence diagram

At first Customer login to the website, send request to system

then if login information true login will be confirmed else return
wrong message to the customer.
Customer started select flight details then the system will check
available offers and return it to the customer.
Customer start payment process and the system checking
payment information; if it is true return successful booking to the
customer else let user check his information again.

2.3. Flight activity diagram

First Customer login to the website, send request to system to get
access to login.
Customer started select flight details(from, to, date, seat) then
the system will check available offers and return it to the
customer.
The Customer continue booking process (cancellation,
payment);to pay its require some information(name, address,
phone number, nationality, bank acc number), then system check
these information; if true confirm payment and return successful
message to the customer else cancel booking and let the
customer to check his information again.

2.4. Flight use case description

2.5. Hotel use case diagram

The customer searches for a hotel then he will check if the

selected room is available, and the customer continues the
booking process and enters payment information then the system
checks this information.

2.6. Hotel sequence diagram

Customer searches for hotel through website and website
returned list of hotels, after selecting the hotel customer will send
request to check available rooms which will be checked in the
database. Also, customers can confirm and cancel bookings
through the website.

2.7.Hotel activity diagram

First the customer opens the website then select the hotel and
check available rooms if the selected room isn’t available, he will
return to the page that contains list of rooms else he will view
prices if it suits him, he will continue booking process else he will
return to hotels page to select another one with his budget.

2.8. Hotel use case description

2.9. Sales use case diagram
2.10. Sales sequence diagram

1. The customer initiates the booking process by sending a

"Book Travel" request to the Sales Department.
2. The Sales Department checks the customer's
creditworthiness by communicating with the Credit Bureau.
3. Depending on the result of the credit check, the Credit
Bureau sends a response indicating whether the credit is
valid or not.
4. If the credit is valid, the Sales Department proceeds to
validate the customer's order using the Order Validation
component.
5. After order validation, the Sales Department updates the
user profile with any relevant information.
 6. Throughout the process, the customer is informed of the
progress and outcomes.
2.11. Sales activity diagram

1. The Sales Department initiates the process by booking

travel upon receiving a request from the customer.
2. A credit check is required, the Sales Department requests
a credit check from the Credit Bureau.
3. The Credit Bureau verifies authorization, checks
creditworthiness, and sends the credit check result back
to the Sales Department.
4. The order details are validated, including price and
availability.
5. If the order is approved, the Sales Department validates
the order and signs it.
6. The user profile is updated, the order is created, and the
customer is notified.
2.12. Sales use case description
2.13. Domain Class Diagram
login(): the user login to the system.
get_flight_details(): Retrieves flight options based on Fdetails(seat, from , where, where, date).
get_car_info(): Retrieves car rental options based on cDetails.

get_available_rooms(): Retrieves available rooms based on hDetails.

confirm_flight_booking(): Confirms the flight booking after customer selection.

confirm_room_booking(): Confirms the room booking.

confirm_car_booking(): Confirms the car booking.

check_in(): Performs check-in for flights or hotel stays.

check_out(): Performs check-out for hotel stays.

check_credit() : Checks the credit credibility of the customer.

validate_order(): Validates the order details and availability of products.

update_user_profile(): Updates user profile for future discounts and packages.

2.14. Design Class Diagram

1. commit:

Delete all relations and description of relations.

2. Attribute:

Add data type of all attributes.

3.Add Methods:

Add all function use in each class.

4.Viewing:

Show which class can view another one.

5.Optional & mandatory (Controller):

Select optional and mandatory classes.

Final Design Class Diagram.

2.15. First cut Design Class Diagram

1. Elaboration Attribute:
Add data type of all attributes.

2. Navigation visibility:

Delete all relations and description of relations.

3. Add controller

2.16. CRC Card.

CRC Card for flight use case.
  First side of card include responsibilities: actions this class
do.
collaboration: other classes integrate with.

 Second side
Include all attributes.

2.17. Communication Diagram.

Customer searches for hotel through website and website returned list of hotels, after selecting
the hotel customer will send request to check available rooms which will be checked in the
database.

Also, customers can confirm and cancel bookings through the website. In this diagram, we use
the same interactions that we made between the user and system components in the sequence
diagram

2.18. Multi-Layer Sequence diagram.

View Layer (User Interface and Customer Interaction):

 The "UI" and "customer" participants represent the view layer, where
user interactions with the system take place.

 The UI displays a booking form to the customer.

  The customer submits the booking info, which is then sent to the Sales
Department.

Data Layer (Database Interactions):

 The "DB" participant represents the data layer, interacting with other
components to store and retrieve data.

 The Credit Bureau retrieves credit data from the database.

 Order Validation retrieves order data, which presumably includes the

customer's order details.

 After the Sales Department checks for discounts, the applicable

discount is applied, and the result is stored in the database.

 The User Profile Update component updates the user profile in the
database, which then sends back a confirmation.

To expand the domain sequence diagram into multi sequence diagram:

1. Include User Interface and Database:

 Add "User Interface" and "Database" components to the diagram to
represent interactions with the user and data storage.
2. Expand on Credit Check:
 Detail the credit check process by showing the Credit Bureau retrieving
and sending back credit data.
3. Add Order Validation Details:
 Show the Sales Department validating the customer's order with more
steps, such as checking order details and product availability.
4. Introduce Discount Process:
 Include steps where the Sales Department checks for discounts and applies
them if the customer is eligible.
5. Detail User Profile Update:
 Expand the user profile update process by showing how the Sales
Department updates the customer's profile in the database.
6. Show Customer Notifications:
 Include interactions where the user interface displays confirmation or error
messages to the customer.

By adding these elements, the simple sales department sequence diagram evolves into the more
complex multi sequence diagram.

2.19. Component Diagram.

User Interface Layer: This represents the front end of the
application where the user interacts with the system.
It contains a browser that makes an HTTP request to the internet.
An internet server sends an HTTP Response back to the browser.
Inside the browser, we have a frame set which might be indicative
of different frames or pages the user can navigate through, with
functionalities such as search, flight reservation, car booking, and
hotel booking.
Authentication is also noted, implying that some form of user
verification is involved.
Domain Layer (Business Logic): This is the back-end part of the
application where the core functionality and data processing
happen.
There are components like a common gateway and application
server, indicating points of access to the business logic layer.
Various services like PHP, reserve management, account
management, and payment processing are depicted, showing the
internal workings of the application server.

2.20. Registration use case diagram.

1. Customer:
 Represents the actor (user) interacting with the system.
2. System:
 Represents the system responsible for handling user
authentication, registration, input validation, and user
creation.
3.Validation & Creation of User:
 Process of validating the input provided during registration
(e.g., username uniqueness, password strength).
  Creation of a new user account in the system upon
successful validation.

3. Electronic Internal output Reports

3.1. Flight internal report

Table Columns:
 ID: This column represents the unique identifier for each flight.
  Season: Indicates the season for which the flight is available. In this case,
it's listed as "All," meaning the flights are available year-round.
 Category: Specifies the category of the flight. In this case, it's listed as
"Domestic," indicating that the flights are domestic flights within the United
States.
 Supplier: This column specifies the airline providing the flight service
(Delta Airlines or United Airlines).
 Unit Price: Represents the standard price for one seat on the flight.
 Special Price: Indicates any discounted price for one seat on the flight.
 Discontinued: Specifies whether the flight is still available ("No" indicates
that the flight is still active).
 Description: Provides details about the type of ticket and the route of the
flight.

Flight Details:
 Each row represents a specific flight with its corresponding details,
including flight ID, category, supplier, unit price, special price, and
description.
 The description typically includes information about the ticket class and the
route of the flight.

3.2. Car Rental Internal Report

We have suppliers such as SIXT and Budget. This internal report
show two types of categories full size/Luxury cars and small cars,
each category ID, number of passengers, unit and special price, Id
of each car and its description.
Supplier: Specify the companies that providing rental cars (SIXT &
Budget).
ID: This column represent the unique identifier for each car.
Category: Specifies the category of the car. In this case it listed
full size/Luxury cars and small cars.
Number of Passengers: Represent number of seats in each car.
Unit Price: Represent the standard price per day.
special Price: Indicates any discount price for car per day.

4. Electronic External output Reports

4.1. Flight external report
 The customer has booked a flight from JFK to LAX.
 There are two flights booked with their respective details such as flight
number, departure time, arrival time, class, and price.
  Payment information includes the method and a truncated card number.
 Passenger details including their names and seat numbers are provided.
 Billing address is included for payment processing.
 Finally, the total cost is broken down into subtotal, tax, and total.

4.2. Car Rental External Report

It shows the order that the customer made. It has details of order
(car id, date of receipt, delivery date, price, quantity, payment
information) for the car he is booking.
5.Design Patterns

5.1. Singleton Design Pattern

BookingSystem Class

The BookingSystem class ensures only one instance of itself is created and provides
global access to that instance through a static method getInstance(). This is
achieved by:

Static Variable: Holds the single instance of the class.

Private Constructor: Prevents instantiation from other classes.

Synchronized getInstance Method: Ensures thread-safe access to the single

instance.
Customer: Represents a customer with properties like username, password, email
address, nationality, name, address, and bank account number. It includes methods
for logging in and checking the credit card.

CarRental: Represents a car rental with properties like ID, unit price, special price,
category, description, and details. It includes methods to check car info, availability,
rental reports, and process payments.

Flight: Represents a flight with properties like ID, unit price, special price, seat,
description, date, destination, and origin. It includes methods to get flight details,
confirm flight booking, and process payments.

Hotels: Represents a hotel with properties like hotel name, unit price, special price,
and details. It includes methods to get available rooms, check-in, check-out, confirm
room booking, and process payments.

SalesDepartment: Represents a sales department with methods to check payment

info, check credit cards, validate orders, and update profiles.

Order: Represents an order with a unique ID and includes order-related methods.

Main Method

The main method in the BookingSystem class demonstrates the usage of the
Singleton pattern and the interaction with the BookingSystem class:

Singleton Instance Creation: Obtains the singleton instance of BookingSystem.

Object Creation: Creates instances of Customer, CarRental, Flight, and Hotels.

Method Calls: Calls various methods on the BookingSystem singleton instance to

simulate logging in, fetching flight details, and confirming bookings.

5.2. Abstract Factory Design Pattern

 BookingService Interface:
 This interface defines the common operations for different types of
booking services: checkAvailability, confirmBooking, and
showDetails.
 Default Methods: getFlightDetails and getAvailableRooms are
default methods that can be optionally overridden by implementing
classes.

 CarRentalImp Class: Implements BookingService for car rentals. It contains

fields for location, start date, and end date. It provides implementations for
checkAvailability, confirmBooking, and showDetails.

 FlightImp Class: Implements BookingService for flights. It includes fields for

the departure location, destination, seat, date, and price. It provides
implementations for getFlightDetails, checkAvailability,
confirmBooking, and showDetails.

 HotelImp Class: Implements BookingService for hotels. It contains fields for

the hotel name, check-in date, check-out date, and price. It provides
implementations for getAvailableRooms, checkAvailability,
confirmBooking, and showDetails.

 BookingFactory Interface: Defines a factory interface with methods to create

car rental, flight, and hotel booking services.

 booking Class: Implements the BookingFactory interface to create instances

of CarRentalImp, FlightImp, and HotelImp with predefined values.

 BookingSystem Class: Uses a BookingFactory to book services. The

bookServices method creates instances of car rental, flight, and hotel
services, displays their details, checks their availability, and confirms their
bookings.
  Unit Test: Tests the BookingSystem by creating a booking factory and a
BookingSystem instance. It calls the bookServices method to ensure the
booking process works as expected.

5.3. Adaptor Design Pattern

This pattern allows objects with incompatible interfaces to work together by
creating a bridge between them.

Components:

SalesDepartment Interface: Represents the target interface for the sales

department operations. It includes methods for checking payment information,
credit card validation, credit validation, and updating customer profiles.

IPayment Interface: Represents the target interface for payment operations. It

includes methods for processing payments and refunding payments.

ExternalPaymentSystem Class: Represents the adaptee, which is the existing

system with incompatible interface. It includes methods for making payments and
refunding transactions.
PaymentAdapter Class: Acts as the adapter, which bridges the gap between the
IPayment interface and the ExternalPaymentSystem class. It implements the
IPayment interface and internally delegates the operations to the corresponding
methods of the ExternalPaymentSystem class.

SalesDepartmentImpl Class: Implements the SalesDepartment interface. It utilizes

an IPayment object to process orders. The processOrder method orchestrates the
order processing workflow by invoking various methods of the SalesDepartment
interface and the IPayment interface.

Main Method:

The main method serves as an entry point to the application. It demonstrates the
usage of the Adapter pattern by creating instances of the ExternalPaymentSystem,
PaymentAdapter, and SalesDepartmentImpl classes. It then processes an order
through the SalesDepartmentImpl object, which internally utilizes the
PaymentAdapter for payment processing.

This code exemplifies how the Adapter pattern facilitates interaction between
incompatible interfaces, allowing seamless integration of different systems or
components within an application.

5.4. Bridge Design Pattern

1. *Abstraction (Booking): *
- *Attributes: *

- #PaymentMethod paymentMethod: A reference to the PaymentMethod

interface.
 - *Methods: *

- +Booking (paymentMethod: PaymentMethod): Constructor to initialize the

booking with a specific payment method.

- +makePayment (amount: double): Method to make a payment using the

associated payment method.

2. *Refined Abstractions: *

- *HotelBooking: * Extends Booking and inherits its methods.

- *FlightBooking: * Extends Booking and inherits its methods.

- *CarRentalBooking: * Extends Booking and inherits its methods.

3. *Implementor Interface (PaymentMethod): *

- *Methods: *

- +processPayment (amount: double): Defines the method that all concrete

payment methods must implement to process a payment.

4. *Concrete Implementors: *

- *CreditCardPayment: * Implements the processPayment method for credit card

payments.

- *PayPalPayment: * Implements the processPayment method for PayPal

payments.

- *BankTransferPayment: * Implements the processPayment method for bank

transfer payments.
5.5. Flyweight Design Pattern

This pattern is used to minimize memory usage and improve performance by

sharing common state between multiple objects instead of each object holding its
own copy of the state.

Components:

CustomerSettings: Represents the settings for a customer, including notification

preferences, language preference, and time zone. It has getters and setters for
accessing and modifying these settings.

CustomerSharedState: Represents the shared state for customers, including

configuration and status. Like CustomerSettings, it also has getters and setters.

CustomerFlyweight: Interface defining the operation for displaying customer details.

This is the Flyweight interface.
SharedCustomerFlyweight: Concrete implementation of CustomerFlyweight
interface. It holds the shared state and implements the display method to show
customer settings and shared state.

CustomerFlyweightFactory: Factory class responsible for creating and managing

flyweight objects. It uses a map to store flyweight objects based on a key generated
from customer ID and settings.

FlyweightPatternDemo: Client code demonstrating the usage of flyweight objects. It

creates multiple instances of CustomerSettings and CustomerSharedState, then
uses the CustomerFlyweightFactory to create flyweight objects based on these
settings. Finally, it calls the display method on each flyweight object to show
customer details.

This pattern is useful in scenarios where a large number of objects need to be

created, but many of them share common state. By using flyweight objects,
memory usage can be reduced significantly.
5.6. Iterator Design Pattern

 Iterator Interface: Defines the methods for iterating over a collection.

 hasNext(): Checks if there are more elements in the collection.

 Next (): Returns the next element in the collection.

 BookingCollection Interface: Defines a method to create an iterator.

 createIterator (): Creates an iterator for the collection.

 BookingIterator Class: Implements the Iterator interface to iterate over the

Booking objects.

 position: Tracks the current position in the list.

 bookings: Holds the collection of bookings.

  BookingIterator (List<Booking>): Constructor to initialize the iterator
with the list of bookings.

 hasNext (): Checks if there are more bookings in the list.

 Next (): Returns the next booking in the list.

 BookingList Class: Implements the BookingCollection interface to manage

bookings and provide an iterator.

 bookings: Holds the collection of bookings.

 createIterator (): Creates an iterator for the collection of bookings.

 addBooking (Booking booking): Adds a new booking to the collection.

5.7. Mediator Design Pattern

1. Mediator Interface

 Mediator

 Methods:

 bookFlight (): Initiates the flight booking process.

 bookHotel (): Initiates the hotel booking process.

 bookCar (): Initiates the car booking process.

 makePayment (): Manages the payment process.

2. Concrete Mediator Class

 SystemMediator

 Attributes:

 customer: Customer: Represents the customer making the

booking.

 flight: Flight: A reference to the Flight class.

 hotel: Hotel: A reference to the Hotel class.

 carRental: CarRental: A reference to the CarRental class.

 salesDepartment: SalesDepartment: A reference to the

SalesDepartment class.

 Methods:

 SystemMediator (): Constructor to initialize the mediator

with required components.

 bookFlight (): Implements the logic for booking a flight.

 bookHotel (): Implements the logic for booking a hotel.

 bookCar (): Implements the logic for booking a car.

 makePayment (): Implements the logic for processing the

payment.
 3. Component Classes

 SalesDepartment

 Methods:

 checkPaymentInfo (): Checks the payment information

provided by the customer.

 CarRental

 Methods:

 confirmCarBooking (): Confirms the booking of a rental

car.

 Hotel

 Methods:

 confirmRoomBooking (): Confirms the booking of a hotel

room.

 Flight

 Methods:

 confirmFlightBooking (): Confirms the booking of a flight.

Relationships

 Inheritance:

 SystemMediator implements the Mediator interface, ensuring that it

adheres to the contract defined by the interface.

 Associations:

 SystemMediator has associations with Customer, Flight, Hotel,

CarRental, and SalesDepartment. These associations indicate that the
SystemMediator interacts with these components to perform its tasks.
5.8. Strategy Design Pattern

1. *Context (bookingcontext):*

- *Attributes: *

- -pricingStrategy: An object of type pricingstrategy.

- *Methods: *

- +bookingcontext (pricingstrategy pricingStrategy): Constructor that initializes

the context with a specific pricing strategy.

- +setPricingStrategy (pricingstrategy pricingStrategy): Method to set or change

the pricing strategy dynamically.

- +calculateFinalPrice (double basePrice, bookingdetails bookingDetails) : double:

Method to calculate the final price using the current pricing strategy.
2. *Strategy Interface (pricingstrategy): *

- *Methods: *

- +calculatePrice (double basePrice, bookingdetails bookingDetails) : double:

Defines the method that all concrete strategies must implement to calculate the
price.

3. *Concrete Strategies: *

- *golduserpricing: * Implements the calculatePrice method for gold users.

- *premiumuserpricing: * Implements the calculatePrice method for premium

users.

- *regularuserpricing: * Implements the calculatePrice method for regular users.

4. *bookingdetails Class: *

- *Attributes: *

- -String bookingDate

- -String destination

- -int numberOfGuests

- *Methods: *

- +bookingdetails (String bookingDate, String destination, int numberOfGuests):

Constructor to initialize booking details.

- +getBookingDate (): String: Getter for booking date.

- +setBookingDate (String bookingDate): Setter for booking date.

- +getDestination (): String: Getter for destination.

- +setDestination (String destination): Setter for destination.

- +getNumberOfGuests (): int: Getter for number of guests.

- +setNumberOfGuests (int numberOfGuests): Setter for number of guests.

5.9. Observer Design Pattern

 Observer Interface:
 update() method, which called to notify Observers of changes.
 Concrete Observer Classes:
 SalesDepartmentObserver & SystemObserver: Implements the
Observer interface and defines the update() method to print a
notification message specific to the Sales Department.
  Customer:
 has methods to set these observers and notify them when the state of
the Customer object changes.
 has references to two observers: salesDepartmentObserver and
systemObserver.
 The main method demonstrates how to use the Customer class with
observers:
 Instantiate a customer object.
 Create SalesDepartmentObserver and SystemObserver objects.
 Set these observers in the Customer object.
 Change the name and email of the Customer.

6. UI
Homepage:
On our website's homepage, there is a header containing the
website's name and buttons for logging in and registering, along
with three options for booking: flight reservations, hotel
reservations, and car rentals. In the main section, exciting and
enticing examples of travel are displayed, along with pictures of
various countries that users can visit. Examples of our affiliated
hotels are also shown. In the footer, there is information about our
company, contact details, and customer service.
flight reservations:

On the second page, which is the flight booking page, the header
contains the name of our company and a logo design. In the main
section, the user fills in details about the trip, including the
destination, departure and return dates, number of passengers,
and type of flight.
hotel reservations:
On the third page, which is the room booking page, the header
remains the same, featuring the company name and logo. In the
main section, there is a form for entering information such as the
number of guests, number of rooms required, check-in and check-
out dates, and destination to display available hotels. Additionally,
there are examples of hotels, villas, and houses that can be
booked. The footer contains the same information as before,
including details about our company.

Car rental:
On the fourth page, which is the car rental page, the header
remains consistent with the company name and logo. In the main
section, there is information about the pickup location, return
time, and a list of car rental companies we collaborate with.
Registration page:
On the registration page, users can create an account if they
don't already have one. The header remains consistent, displaying
the company name and logo. In the main section, users input
information such as their first name, last name, email address,
account password, and nationality. Additionally, there is a button
to complete the registration process.
LOGIN Page:

On the login page, users can input their account credentials,

including their username and password. Alternatively, they can
choose to log in using their Google, Facebook, or Apple accounts,
with three buttons provided for selection.
PAYMENT Page:

Additionally, there is a page for payment via Visa. Here, users

input their credit card information to complete the payment
process.