TV2 - OOAD Case Study- Flight Systems.pdf

TV2 – Case Study: Booking Systems
Software Engineering
Computer Science
Academic Year 2023/2024
Gerard Albà Soler
1

Case Study: Booking Systems
1. Travel Agency web System
- Questions Case study 1
2. Decentralized web3 Booking System
- Questions Case study 2
3. Appendix:
- Blockchain
- Decentralized Booking Systems

The assignment TV2 is divided in two parts. We will analyse and design (OOAD) two
systems for travel and flight booking.
1. The first one is a traditional website/App system for a travel agency (hotels,
flights etc).
2. The second one is a web3/DApp (Blockchain-based) decentralized (peer-to-peer)
system for bookings (flights).
In system 1 (web2), computers use unique web adresses to find the information,
which is stored at a fixed location (server). This is based on http protocols.
In system 2 (web3), information will be found based on its content, and can be stored
in mutiple locations (decentralized). This is based on blockchain protocols.

Part I: Case Study Travel Agency
• A traditional travel agency wants to go digital as it is convinced that it is necessary
for its survival. The company knows that it needs an online reservation system but
has doubts about the functionalities that it should have.
• The process manager of the travel agency has met with the project manager of the
company you work for, and these are some of the points they agree to be used as a
starting point for the analysis phase.

Catalog management
• The catalog currently has about 1000 accommodations. There is a sales team that is
responsible for updating it (add, edit, or delete hotels).
• When a new accommodation is added, the system reminds the sales agent that he can
associate it to an existing provider account or to a newly created one.
• The provider account can be added at the time of creating the accommodation or it can be
added in a separate process.
• Providers can use their accounts to edit an accommodation that is assigned to them or to
add offers to their accommodations. Offers must include start date, end date and discount
percentage.
• When a hotel receives three negative reviews within 15 days, it is deactivated and
becomes part of the non-recommended hotels. Only sales agents can put a hotel back on
the list of recommended hotels.

Reservation process
• The clients have three options to find an accommodation. For each of them, the first thing
they must do is select a destination:
• Customers can navigate through the promotions and see if any of the published offers
fits its needs. They can then access the details page to make a reservation.
• Directly entering the name of the hotel where he wants to stay. The user will be
redirected to the detail page directly.
• Go to the advanced search section where he can filter using the start date, end date
among others. All the accommodations that meet the search criteria will be listed and
the user will be able to choose any of them to access the hotel details page.

• A reservation can be initiated from the detail page of the accommodation. The client must
access his client account or create a new account to be able to make a reservation.
• During the travel reservation process the client can add several additional services such as:
ü Travel insurance
ü Car reservation at origin: This option allows the customer to travel to his destination
with the rented car. If this option is selected, he must choose the car company (avis,
hertz or europcar) and the car model.
ü Car reservation at destination by selecting the company (avis, hertz or europcar), the
dates (not necessarily the same as the trip) and the car model.
ü Plane tickets: must choose the origin airport.
• Customers should also be able to book a rental car or plane tickets independently.
• A few days after the end date, customers are asked to rate the service received. To do so,
they must connect to their account and access their reservations management section.

Payment management
• Client must be authenticated.
• The client can make the payment at the time of making the reservation, accessing the reservation
management section or in cash at the agency.
• When a client makes a payment, he can do so for the entire reservation or for an amount that he
chooses.
• Payment can be made in as many installments as the client wants, the only requirement is that the
trip is fully paid 15 days before the start of the trip.
• The client can cancel a reservation that has pending payment, on the other hand, if the reservation
has not been fully paid 15 days before the start of the trip, it is canceled automatically.
• The system will notify customers of reservations that have not been paid in full once a month.
Reporting
• All agency employees can request reservation reports for the last month, semester, and year.

Questions:
1. Create a use case diagram for the case study case.
2. For the use case, “make a reservation” write the textual specification. Indicate, with
details, what the system does, and the actors involved in the use case and the data
exchanged in the interactions. Create a system sequence diagram.
3. We also want to create a class diagram of the domain . Explain each of the following
class diagrams and validate if the modeling captures the structural features of the
system.

Class diagrams: Hotel

Class diagrams: Reservations

Class diagrams: Payments

Part II: Case Study Blockchain Flight System
• Travel has long been dominated by centralized booking platforms, like the system 1
analysed before.
• But the next big thing in travel innovation could be decentralized systems, as
contrast to centralized platforms, that could allow travelers to deal directly with
travel suppliers like hotels, car rentals, insurance, and airlines.
• An airline consortium (a group of airlines) wants to build an innovative
permissioned decentralized system 2 for flight bookings.
• The process manager of the consortium has met with the project manager of the
company you work for, and these are some of the points they agree to be used as a
starting point for the analysis phase.

Decentralized airline system
• The airline consortium (we will call it ASK) new system should enable peer-to-peer transactions of
flight seats among participant airlines.
• Airlines can go about their routine business with their traditional centralized distributed systems and
manual agents. Besides, they can participate also in the permissioned, decentralized consortium.
• Airlines may join and leave the system as they wish. They join ASK by depositing a predetermined
minimum escrow used for payment settlement for seats used in ASK transactions. The consortium
allows an airline to trade (buy and sell) flight seats under certain circumstances and conditions.
• The airline representatives can initiate the trades proactively or reactively in response to customer
demand or as warranted by circumstances such as weather-related cancellations. In this use case,
you’ll limit the scope to the elemental operation of peer-to-peer sales of flight seats among airlines.
Enforcement of agreed business rules of engagement and a payment system is also enabled.
• The participating airlines expose secure, standard APIs for simple queries about the availability of
flight seats. An application requests trades from the airlines directly on your behalf.

Operations

Operations
1. A customer initiates a change of flight seat that they hold on airline A.
2. An agent or application at airline A verifies and validates the request through smart contract (logic shared among the ASK
consortium members).
3. Once verified, the request Tx is confirmed and recorded in a distributed immutable ledger (Blockchain, see Appendix).
Now everyone in the consortium knows that a legitimate request has been made.
4. In the simplest design, an agent at airline A sends the verified and validated request (VVRequest) to airline B.
(Alternatively, we could use a model in which many airlines get the request, and any one of them could respond.)
5. An agent or application at airline B checks the airline’s database to check for availability.
6. An agent at airline B responds (through shared smart contract logic) so that verifies and validates the common interests
and shared rules of the consortium.
7. Once verified, the response Tx is confirmed and recorded in a distributed immutable ledger. Now everyone in the
consortium knows that a response has been sent.
8. Airline B sends the response (indicated by VVResponse) to the agent at airline A.
9. Airline A updates its database, noting that a change has been made.
10. An agent at airline B sends the customer the information for the flight seats and other details. (Note that airline B holds
its data assets and transfers them directly to its known customer, not to airline A).
11. Payments are settled through peer-to-peer Txs, using the escrow or deposit that participating airlines hold in their shared
smart contract. The payment settlement can be embedded in other suitable operations in the system but will be handled
by the shared smart contract and recorded in the ledger. This settlement is automatically carried out by the smart
contract logic.

Example of Operations
• At the airport, you see display boards for
flights departing from and arriving at
destination.
• You could picture one more display board:
the ASK display that shows the available
seats on flights departing from that airport.
• Right chart shows examples of the three
displays: arrivals, departures, and available
seats (the ASK display).
• The ASK display is a new display of available
seats that is not currently available at the
airports. It is a new concept introduced by
the ASK application.

• If you want to switch to a different flight, you can check the ASK display to see whether a seat
that meets your needs is available. If so, you can approach the airline on which you hold your
current seat (fromAirline) and ask it to facilitate the change, specifying the airline to which you
would like to switch (toAirline). Agents of the airlines process your request by using the ASK UI,
assign the seat to you, and message you about the status of your transfer. Payment is settled
between the airlines via the smart contract based on previously deposited amounts and any
business contracts established between them.
• Airlines interested in the ASK model join (register with) the ASK consortium by paying a deposit
and applying to become ASK members. ASK member airlines are responsible for updating
information about available seats on the ASK display board (off-chain data).
• The ASK consortium authority will have a monitor, whom you will refer to as the chairperson of
the consortium. This consortium does not mean centralization, because this monitoring or
chairperson role is periodically circulated among the consortium members. The chairperson of
the consortium has the sole authority to unregister members and return leftover deposits.

• An example scenario to show the typical operation of the ASK Dapp (Decentralized Application):
- Suppose that a customer who holds a seat on a flight operated by AirlineA finds and wants to
change to a seat on a flight operated by AirlineB leaving at 1 p.m.
- The customer makes a request to AirlineA to change their seat. An agent at AirlineA issues a
request (ASKRequest()) to AirlineB on the customer’s behalf to confirm that the seat is available.
- An agent at AirlineB examines its system and responds (ASKResponse()). Assuming that the
response is a success response (the seat is available), AirlineA initiates payment to AirlineB, and
the ASK display is updated to show the number of seats now left on the flight with flightID 5.
- Other updates related to the seat vacated by this customer on the original flight also happen
offline, but they are not shown here. Either of the airlines involved may message the customer
about the change, and all the ensuing operations are carried out offline.
- Most of the operations are offline except for proof that the request was issued, the the transfer
took place, and payment was settled, that are registered on the Blockchain.

Decentralized system: business model benefits

System and Smart Contracts
• A decentralized system is based on Smart Contracts. We will not go into technical details (See
Appendix to learn more).
• The smart contract acts as the brain of a blockchain application (for example on the Ethereum
blockchain. Bitcoin blockchain does not allow complex Smart contracts).
• It is responsible for many vital functions, including the following:
ü It represents a business logic layer for verification and validation of application-specific
conditions.
ü It allows for the specification of rules for operations on the blockchain.
ü It facilitates the implementation of policies for the transfer of assets in a decentralized network.
• For our system 2 problem, we can basically asume that “the system” to analyse and design are
equivalent to a smart contract. The solution to our problem is to design this specific smart contract
for our use case.
https://youtu.be/5-RnrDQSTBo?si=BLimOBtszpf932NB

Analysis and Design of Smart Contracts
• There are UML diagrams, similar to class
diagrams, to model the structure of a Smart
Contract in OOAD . They are called contract
diagrams.
• The contract diagram is a convenient UML
artifact for design discussions with
stakeholders and the development team.
• The UML notation has six diagrams to
model the structure of object oriented
systems. Since smart contracts are very
similar to classes, we can use UML diagrams
with little adaptation. Therefore we can
model an object oriented application and
its blockchain structure by using UML.
https://youtu.be/zq410r7A9tk?si=-
vg7zAzANk9ErFKa
Class vs Contract

Questions:
• Before we code, develop and deploy the new ASK system 2, we must analyse and design
it well. We could use the same modeling techniques learnt for OOAD in Modules 1-5 of
the course.
• Implementation could be done using OO Solidity programming language. Testing of the
system is also usually done in a test chain (we test our smart contracts - the system - in a
test blockchain)
1. Explain the use case diagram for the study case, as shown on the next slides.
2. For the main use case, “flight seat booking”, explain the system UML sequence
diagram shown.
3. We also want to create a class diagram. Explain the contract diagram shown.
4. Explain the SDLC of the Dapp, that includes the system and a GUI, according to the
next figure.

Question 1:
1. Explain the use case diagram for the study case

Question 2:
2. For the main use case,
“flight seat booking”, explain
the system UML sequence
diagram shown

Question 3:
3. Explain the contract diagram shown

Question 4:
4. Explain the SDLC of the
Dapp, that includes the
system and a GUI, according
to the next figure.

Appendix: Blockchain
• Bitcoin : peer-peer cryptocurrency that does not require a middle entity such as a
bank to complete a transaction between the sender and receiver.
• Created by a secretive person(s) known as Satoshi Nakamoto.
• Runs on the Internet.
• To keep track of the transactions, an ingenious ledger technology has been devised.
• This ledger is distributed and is a collection of blocks of transactions.
• How do you trust the ledger? The trust model out of this distributed ledger is an
important contribution of Bitcoin.
• The distributed ledger and associated concepts are called the “blockchain”.
• Bitcoin technology is the genesis for the advent of blockchain revolution.

• Blockchain is not just about cryptocurrency (or Bitcoin) anymore:

• Trust is a critical component for
trade and any type of business
transaction.
• Blockchain is about “trust
automation”.
• Bitcoin, for example allows this
“trust” in a new peer-to-peer
(decentralized) way.
• Traditional centralized systems
require intermediaries (third-
parties).

• Blockchain is a Distributed
Immutable Ledger (DLT)
• Trust and Security are achieved
by defining verification,
validation, consensus and
integrity

• Therefore, blockchain is about:
- Decentralization
- Disintermediation
- Distributed Immutable Ledger
• Blockchain is a trust layer on the internet.
• Strong foundation of >40 years of scientific research (cryptography, hashing, consensus protocols).

• You can learn more about Blockchain and smart contracts here:
https://www.youtube.com/playlist?list=PLVext98k2evgrxnjH1uweNPeeV_SXX7dA

Appendix: Decentralized Booking Systems
• Envision a Network of Peers to Peers: Decentralized solutions, as contrast to centralized
platforms, allow travelers to deal directly with travel suppliers like hotels and airlines. By
doing this, the middleman is cut out, which may result in reduced costs and more control
over reservations.

Appendix: Decentralized Booking Systems
• Blockchain: An Encrypted Record. This is the point of magic. Blockchain is a distributed ledger
system that is secure. Every aspect of your reservation, including the flight and hotel data, is
stored in encrypted blocks. A tamper-proof record is produced by temporally chaining these
blocks together. It operates as follows, step-by-step:
ü Look for and Selection: Using a decentralized booking platform, you look for hotels or
flights. These systems provide direct connections with databases that hotels and airlines
manage.
ü Booking Initiation: After selecting your travel options, you make a direct reservation
with the platform’s provider.
ü Activation of a Smart Contract. This is when a self-executing program recorded on the
blockchain called a smart contract comes into play. The terms of the reservation, such
as the cost, the cancellation policy, and the payment information, are described in this
contract.

• References to learn more:
Dapp for Flight booking:
ü https://github.com/sapph1re/flight-tickets?tab=readme-ov-file
ü https://youtu.be/1UF5LnCs5Ps?si=r6O_M-hX-q8g4BeQ
ü https://medium.com/@subashreevjc/deep-dive-into-decentralized-booking-systems-c1e043bafdbf
UML diagrams and OOAD for Blockchains:
ü https://github.com/naddison36/sol2uml
Blockchains:
ü https://youtube.com/playlist?list=PLVext98k2evgrxnjH1uweNPeeV_SXX7dA&si=HvWlLkEEPO-N_Vp9

TV2 - OOAD Case Study- Flight Systems.pdf

More Related Content

Similar to TV2 - OOAD Case Study- Flight Systems.pdf

More from Gerard Alba

Recently uploaded

TV2 - OOAD Case Study- Flight Systems.pdf