Software Design Document: Bike Reservation System

Software Design Document
For
Golden Bike Shop:

Bike Reservation System
Prepared by
February 7th, 2020

High Level Project Description:
The Bike Reservation System (BRS) requested by the Golden Bike Shop for development and
implementation is a new system that will free up employee time by allowing customers to rent bikes
through an application. The application can be accessed on either a desktop or mobile device through a
web browser, or in-store on a tablet configured with a swipe-to-pay billing system. The BRS exposes the
ability for a customer to reserve a bike ahead of time or reserve in-store for a selected time period. The
BRS also allows customers to select a date and search by bicycle type.
In addition to these features that benefit the customer, the BRS allows employees, managers, and
administrators to use the system. Employees can make notes on the condition of the bike when it is
returned, managers can adjust bike rental rates and late or change fees, and administrators can
generate reports. Overall, the system enhances the bike rental process for customers, employees,
managers, and administrators.
The internal stakeholders involved in this project are the owners of the Golden Bike Shop that are
funding this project. Their role is to give the development team a statement of work. Internal
stakeholders also include the employees, managers, and administrators of the bike shop.
The external stakeholders involved in this project are the customers of the bike shop who use the
software to rent and reserve bikes. Their entire experience is directly affected by this project.
Refined Requirements
Refined requirements for the Bike Reservation System (BRS) include the following:
• The Golden Bike Shop has tablets for customers to use when reserving a bike through the BRS in the
store
• The in-store tablets have a swipeable card reader for in-store customers to use when providing
payment information to the BRS
• When administrators are viewing reports generated by the BRS, they simply view it on their device
(they do not print it)
• The reports generated by the BRS do not need to be saved, they are simply a view on top of
underlying class entity objects
• The Golden Bike Shop only accepts payment in the form of credit cards
• A customer can only have one credit card on file at a time
• The BRS only accept U.S. addresses for billing information at this time
• When a customer swipes their card in the store, they must provide a signature which is approved by
the BRS
• Online customers can enter billing payment information that is different than their contact
information
• If a customer tries to cancel a reservation more than 24 hours ahead of their reservation start date, a
cancellation charge is charged to their card but the cancellation succeeds. If a customer tries to cancel
a reservation less than 24 hours ahead of their reservation start date, the cancellation does not
succeed.
UML Use Case Diagram
Below is the full Use Case Diagram for the Golden Bike Shop Reservation System.
Note: Please zoom in to 200% or more to view.

The full use case diagram is broken up into smaller pieces below, providing better visualization to
accompany each use case description.
Use Case Name: Search Inventory
Use Case Id: BRS-1
Primary Actor(s): Customer
Secondary Actor(s): ---
Brief Description: Customer searches the inventory of the bike shop
Preconditions: Customer navigates to the website of the BRS

Flow of Events: 1. Customer begins an inventory search.
2. The BRS displays the types of bicycles, which the
customer can choose to filter the inventory search with.
3. The customer executes the inventory search.
4. The BRS displays the available inventory.
a. The BRS filters the inventory by search criteria, if
provided.
Post Conditions: The customer search results are displayed.
Priority: Medium
Alternative Flows and ---

Directions:
Non-behavioral ---
requirements:
Assumptions ---
Issues: ---
Source: Golden Bike Shop Case Study

Use Case Name: Select Bike(s) on Specific Day
Use Case Id: BRS-2
Brief Description: The customer selects a bike to reserve.
Preconditions: The customer has performed an inventory search filtered by the

type of bike they want to rent.
Flow of Events: 1. The customer selects a date range.

2. The BRS displays the available inventory for the date
range.
3. The customer selects a bike or bikes.
4. The BRS reserves the bikes and marks them unavailable.
Post Conditions: The bike(s) that the customer selected are marked unavailable
in the system, meaning no other user can select them at this
time.
Priority: High

Directions:
Non-behavioral ---
requirements:
Assumptions Once a bike is selected, it is marked unavailable in the system.

When a bike is marked unavailable in the system, it will not
show up in the inventory search for available bikes and no other
user will be able to select it.
Issues: ---
Use Case Name: Enter Payment Information
Use Case Id: BRS-3
Primary Actor(s): Online Customer
Secondary Actor(s): External Payment System
Brief Description: The online customer enters their payment information into the
BRS web app interface.
Preconditions: The online customer has searched the inventory for a bike they
want, and has selected the bike for a specific day.
Flow of Events: 1. The BRS prompts the user to enter their payment
information.
2. The user enters their payment information.
3. The external payment system validates the payment
information.
4. The payment information comes back valid.
5. The customer is cleared for the bike rental.
Post Conditions: The bike is considered “rented” for that time period and the
customer is responsible for physically picking up the bike for the
period they rented it for.
Priority: High
Alternative Flows and 1. The BRS prompts the user to enter their payment
Directions: information.
2. The user enters their payment information.
information.
4. The payment information comes back invalid.
5. The system displays a payment invalid message.
6. The customer is not cleared for rental and the bike is
marked available again in the system.
7. The customer’s reservation process is restarted.
Non-behavioral The external payment system must be available 24/7 to validate

requirements: payment information, since the primary actor is an online
customer and could make a reservation at any hour of the day.
Assumptions The online customer is reserving the bike ahead of time,

meaning they must enter their payment information (instead of
swiping it). The online customer inherits from the customer, so
they can do everything the customer can do, but with the added
functionality/capability of entering their payment information.
Issues: ---

Use Case Name: Swipe Payment Information
Use Case Id: BRS-4
Primary Actor(s): In-Store Customer
Brief Description: The in-store customer swipes their payment information
Preconditions: The in-store customer has searched the inventory for a bike
they want, and has selected the bike for a specific day.
Flow of Events: 1. The BRS prompts the user to swipe their payment
information.
2. The user swipes their payment information.
information.
4. The payment information comes back valid.
5. The customer is cleared for bike rental.
Post Conditions: The bike is considered “rented” for that time period and the
customer is responsible for physically picking up the bike for the
period they rented it for.
Priority: High
Alternative Flows and 1. The BRS prompts the user to swipe their payment
Directions: information.
2. The user swipes their payment information.
information.
4. The payment information comes back invalid.
5. The system displays a payment invalid message.
6. The customer is not cleared for rental and the bike is
marked available again in the system.
7. The customer’s reservation process is restarted.
Non-behavioral The swipe-to-pay feature needs to be available during business

requirements: hours of the Golden Bike Shop, since this feature is only
available to in-store customers.
Assumptions The in-store customer is reserving the bike in the store,

meaning they must swipe their payment information (instead of
entering it). The in-store customer inherits from the customer,
so they can do everything the customer can do, but with the
added functionality/capability of swiping their payment
information.
Issues: ---

Use Case Name: Cancel Reservation
Use Case Id: BRS-5
Brief Description: The customer cancels a reservation.
Preconditions: The customer has made a reservation.
Flow of Events: 1. The customer cancels a reservation.

2. The customer’s payment information is charged a
cancellation fee.
3. The bike is marked as available again in the system.
Post Conditions: The bike is considered “available” in the inventory, and will
show up in a search of the available inventory.
Priority: Medium
Alternative Flows and 1. The customer cancels a reservation.

Directions: 2. The cancellation is denied because it is not 24 hours
before the reservation.
3. An error message is displayed that says “Cancellation is
not allowed”.
Non-behavioral ---
requirements:
Assumptions ---
Issues: ---

Use Case Name: Return Bike(s)
Use Case Id: BRS-6
Brief Description: The customer returns the bike to the store and marks it
returned in the BRS.
Preconditions: ---
Flow of Events: 1. Bike is physically turned in by the customer

2. Customer marks the bike as returned on the BRS
3. BRS uses an algorithm to determine if a late fee
should be applied
i. If yes, the BRS applies the late fee
ii. If no, the BRS does not apply the late fee
4. The external payment system charges the
payment information provided by the BRS
Post Conditions: ---
Priority: High

Directions:
Non-behavioral ---
requirements:
Assumptions The customer shows up for the bike return day.
Issues: If the bike is returned damaged, late or not at all.

Use Case Name: Process Bike Return
Use Case Id: BRS-7
Primary Actor(s): Employee
Brief Description: Employee must re-rack and update the system to show the bike
as returned.
Preconditions: Bike has passed inspection and the customer showed up.
Flow of Events: 1. Employee checks the BRS and sees a customer

marked a bike for return.
2. Employee physically finds the bike and inspects
for damage.
i. If damage, employee records the rental
problems and repairs the bike.
3. Employee checks to see if customer called ahead
of time about the bike being late.
i. If yes, the employee uses the BRS to
reduce the late fee.
ii. The external payment system refunds the
partial late fee amount provided by the
BRS.
4. Employee physically puts bike back in inventory
and uses the BRS to mark the bike as available.
Post Conditions: Bike will show up in database and be ready for rent!
Priority: High

Directions:
Non-behavioral Bike is in acceptable condition to be rented out.

requirements:
Assumptions Bike has little if any damage.
Issues: ---
Use Case Name: Set Charge
Use Case Id: BRS-8

Primary Actor(s): Manager
Brief Description: Managers can use the BRS to update the charge amount for
reservation changes and reservation cancellations.
Preconditions: ---
Flow of Events: 1. Manager accesses the BRS app with special admin
credentials.
2. Manager updates the charge amount for reservation
changes.
Post Conditions: The new values for reservation change charges and reservation
cancellation charges are reflected in the system.
Priority: Low
Alternative Flows and 1. Manager accesses the BRS app with special admin
Directions: credentials.
1. Manager updates the charge amount for reservation
cancellations.
Non-behavioral The manager must be able to update these values at any time of
requirements: the day.
Assumptions ---
Issues: ---

Use Case Name: Set Bike Rental Rate
Use Case Id: BRS-9
Brief Description: Based upon bike type the manager needs to set a price to be
used in charges calculation.
Preconditions: ---
Flow of Events: 1. Manager accesses the BRS with special admin

credentials.
2. Manager specifies the type of bike.
3. Manager optionally specifies a period for the updated
rate period.
4. Manager enters a value for the rental rate.
Post Conditions: The updated rental rate for the type of bike is reflected
throughout the BRS.
Priority: Low

Directions:
Non-behavioral ---
requirements:
Assumptions ---
Issues: ---
Use Case Name: Adjust Inventory
Use Case Id: BRS-10
Brief Description: Manager needs to be able to add or remove bikes from the
database.
Preconditions: ---
Flow of Events: 1. Manager accesses the BRS with special admin

credentials.
2. Manager begins the “add bike to inventory” process.
3. The BRS prompts the manager to describe the bike.
4. Manager describes the bike and submits the update
request.
5. The BRS adds the bike to the inventory and marks the
bike available for rent.
Post Conditions: Greater number of bikes will be available for use.
Priority: Low
Alternative Flows and 1. Manager accesses the BRS with special admin
Directions: credentials.
2. Manager begins the “remove bike from inventory”
process.
3. The manager selects the bike to remove and submits the
request.
4. The BRS marks the bike as unavailable in the system.
Non-behavioral ---
requirements:
Assumptions ---
Issues: ---

Use Case Name: Generate Summary Report
Use Case Id: BRS-11
Primary Actor(s): Administrator
Brief Description: Feature that will print out itemized report for owner/manager.
Preconditions: Employee has enough permissions to view/print everything.
Flow of Events: 1. Administrator accesses the BRS with special admin

credentials.
2. Administrator begins the “Generate Summary Report”
process.
3. The BRS generates the summary report that includes an
inventory description and inventory rental history.
Post Conditions: Formatted report is ready to be reviewed.
Priority: Low

Directions:
Non-behavioral ---
requirements:
Assumptions ---
Issues: ---
Use Case Name: Generate Individual Bike Report
Use Case Id: BRS-12
Primary Actor(s): Administrator

Brief Description: Admin will need to filter through inventory and select a specific
bike to generate a report for.
Preconditions: ---
Flow of Events: 1. Administrator accesses the BRS with special admin

credentials.
2. Administrator begins the “Generate Individual Bike
Report” process.
3. The BRS prompts the administrator to select the bike for
the report.
4. The administrator selects the bike.
5. The BRS generates the individual bike report which
includes the rental inspection problems, the
maintenance problems, and the rental history of the
bike.
Post Conditions: Report is ready for review.
Priority: Low

Directions:
Non-behavioral Bike needs to be present in inventory (even if decommissioned)

requirements:
Assumptions ---
Issues: ---

System Context Class Diagram
Note: Please zoom in 200% or more to view.

Entity Class Diagram
Note: Please zoom in 200% or more to view.

Class Purpose and Description Tables
1. Bike class is referenced by a Reservation class, is stored in the Inventory class, and maintains bike
information that includes the following attributes:
Attribute Name Data Type Description

bikeId Integer Bike unique ID
make String Designates the brand
who makes the bike
model String Designates the model of
the bike
type String The type of the bike
(performance,
recreational, children)
rentalPrice Real Cost to rent the bike
flexRentalPricePeriod [StartDate: Date, EndDate: Flex price period in which the
Date, flexPrice: Real] rental price of a bike can be
increased during a special
time like a holiday
isInService Boolean Whether the bike is in

service or not (i.e. if it
has been returned to
service after an
employee has inspected
it, or if its out for
maintenance, and will
affect whether or not it
shows up in an
inventory search)
2. Inventory class maintains a collection of bikes that are searchable by customers, adjusted by
managers, and analyzed by administrators:

bikes Bike[ ] The collection of bikes
that is in the inventory
3. Administrator class maintains information about an administrator that includes the following
attributes:

administratorId Integer Administrator unique ID
administratorName String Name of the
administrator
4. Manager class maintains information about a manager that includes the following attributes:

managerId Integer Manager unique ID
managerName String Name of the manager
5. SystemPrices class maintains system-wide, singleton information about prices, which can be adjusted
by managers, and is used by the Reservation class to determine final charge amounts:

reservationChangeChar Real The standard extra fee
ge applied to reservations
that have been changed
reservationCancellation Real The standard extra fee
Charge applied to reservations
that have been
cancelled
6. Reservation class maintains information about a reservation, and references one or more Bike classes
to designate which bikes belong to the reservation:

reservationId Integer Reservation unique ID
startDate DateTime The date/time when the
reservation starts
endDate DateTime The date/time when the
reservation ends
customerId Integer The unique ID for the
customer who created
the reservation
isChanged Boolean Whether the reservation
has been changed by
the customer
isCancelled Boolean Whether the reservation
has been cancelled by
the customer
isReturned Boolean Whether the bike or bikes on
the reservation have been
returned to the customer
rentalCharge Real Sum of the rental

charges for the bikes
attached to the
reservation for the
specified date range
additionalCharge Real Any additional charges
associated with the
reservation (cancelled,
changed, late)
notes String Any notes entered by
the employee upon
return of the bike/ bike
inspection
7. Employee class maintains information about an employee that includes the following attributes:

employeeId Integer Employee unique ID
employeeName String Name of the employee
8. Customer class maintains information about a customer that includes the following attributes:

customerId Integer Customer unique ID
customerName String Name of the customer
address String Address of the customer
telephoneNumber String Telephone number of
the customer
reservations Reservation [ ] A collection of any
reservations the
customer has created
9. CustomerPaymentInformation class maintains information about the customer’s payment info that
includes the following attributes:

paymentInfoId Integer Unique ID for the
customer payment
information
cardType String Type of card (ex. Visa)
cardNumber String Credit Card number
card3DigitCode String 3 digit authorization
code for the credit card
10. InStorePaymentInformation class inherits from the CustomerPaymentInformationClass and

maintains information about the customer’s in store payment information that includes the following
attributes:

signatureApproved Boolean Whether the customer’s
signature is approved
after they swipe their
card and digitally sign
on the tablet
11. OnlinePaymentInformation class inherits from the CustomerPaymentInformationClass and maintains

information about the online customer’s payment information that they typed in manually, which
includes the following attributes:

billingFirstName String Billing information first
name
billingLastName String Billing information last
name
billingStreetAddress String Billing information
street address
billingCity String Billing information City
billingState String Billing information State
billingZipCode String Billing information zip
code
12. QueryTransaction class references CustomerPaymentInformation (and the Reservation) to verify the
payment information can cover the cost of the rentalCharge in the Reservation, and includes the
following attributes:

queryTransactionId Integer Unique ID for the query
transaction
reservationId Integer Reference to the unique
ID of the reservation
paymentInfoId Integer Reference to the unique
ID of the payment
information provided
timeStamp DateTime Timestamp for when the
query transaction
occurred
isApproved Boolean Whether the payment
information has been
approved/verified (a.k.a
it can cover the cost of
the rental)
13. PaymentTransaction class references CustomerPaymentInformation (and the Reservation) to charge

the payment information provided, and includes the following attributes:
paymentTransactionId Integer Unique ID for the
payment transaction
totalPaymentAmount Real Total payment amount,
includes the
rentalCharge +
additionalCharge
captured from the
referenced Reservation
totalRefundAmount Real Total refund amount, if any
reservationId Integer Reference to the unique

ID of the reservation
paymentInfoId Integer Reference to the unique
ID of the payment
information
timeStamp DateTime Timestamp for when the
query transaction
occurred
System Objects and Use Case Participations

The BRS is a mobile/web application, requiring it to rely heavily on
keypad/display user interfaces on mobile or web devices. Analyzing the
System Context Diagram reveals the following interface objects:
Device Interface Objects
<<I/O device interface>>
• SwipeableCardReaderInterface: through which an in-store customer’s

payment information is input into the system and outputs the colored light
to indicate valid or invalid payment information
User Interface Objects
<<user interface>>
• InStoreCustomerTabletKeypadDisplayInterface: which accepts in-store

customer commands and prompts the customer throughout the
reservation process
• OnlineCustomerWebBrowserInterface: which accepts online customer

commands and prompts the customer throughout the reservation process
• ManagerMobileWebDeviceKeypadDisplayInterface: which accepts

manager commands and prompts the manager
• EmployeeMobileWebDeviceKeypadDisplayInterface: which accepts

employee commands and prompts the employee
• AdministratorMobileWebDeviceKeypadDisplay: which accepts the

administrator commands and prompts the administrator
System Interface Objects
<<system interface>>
• ExternalPaymentSystemInterface: communicates with the credit card

company
Coordinator Objects
<<coordinator>>
• CustomerCoordinator: coordinates requests from customers to interact
with the system
• ManagerCoordinator: coordinates requests from managers to fulfill

requested actions
• EmployeeCoordinator: coordinates requests from employees to fulfill

requested actions
• AdministratorCoordinator: coordinates requests from administrators to

generate reports
Service Objects
• BikeInventoryService: interacts with coordinators to retrieve, update, and

persist data that has to do with Bikes or the Inventory
• ReservationService: interacts with coordinators to retrieve, update, and

persist data that has to do with Reservations or anything associated to a
Reservation
• SystemManagementService: interacts with a Manager coordinator to

persist system-wide prices
The objects laid out above participate in the use cases in the following ways:
BRS-1: Search Inventory
InStoreCustomerTabletKeypadDisplayInterface: Since the in-store customer

actor interacts with the BRS to search the inventory, this user interface
object is needed to receive commands from customers and prompt
customers for input
OnlineCustomerWebBrowserInterface: Since the online customer actor

interacts with the BRS to search the inventory, this user interface object is
needed to receive commands from customers and prompt customers for
input
Inventory: This is an entity object needed to maintain the collection of Bikes

that a customer can search upon
Bike: This is an entity object needed to maintain information about a bike

(like the type of bike) so that a customer can use that information to filter
the inventory search
CustomerInteraction: This is a user interaction interface needed to interface
with the
OnlineCustomerWebBrowserInterface/InStoreCustomerTabletKeypadDisplayI
nterface and forward requests to the CustomerCoordinator
CustomerCoordinator: This is a coordinator object needed to coordinate the

search request performed by the customer
BikeInventoryService: This is a service that interacts with Bikes and

Inventory to perform a search and return the results to the
CustomerCoordinator
BRS-2: Select Bike(s) on Specific Day

actor interacts with the BRS to select a bike(s) on a specific day, this user
interface object is needed to receive commands from customers and prompt
customers for input

interacts with the BRS to select a bike(s) on a specific day, this user
interface object is needed to receive commands from customers and prompt
customers for input
Reservation: This is an entity object needed to maintain information about a

reservation that a customer creates in this use case
Bike: This is an entity object needed to maintain information about a bike

and allows a customer to create a Reservation with one or more of this
object attached to it
Customer: This is an entity object needed to keep track of reservations for a

customer when they select a bike on a specific day (a.k.a create a
reservation)

with the
OnlineCustomerWebBrowserInterface/InStoreCustomerTabletKeypadDisplayI

select bike (create reservation) request from the customer
ReservationService: This is a service that interacts with the Customer

Coordinator and creates/saves reservations
BRS-3: Enter Payment Information

interacts with the BRS to enter their payment information, this user interface
customers for input
ExternalPaymentSystemInterface: This system interface object is needed to

communicate with the BRS to validate payment information entered by the
user
CustomerPaymentInformation: This is an entity object needed to maintain

payment information provided by the online customer
OnlinePaymentInformation: This is an entity object needed to maintain

extended payment information provided by the online customer, which can
be different than the customer’s contact information
QueryTransaction: This is an entity object needed to maintain information

about the query transaction to validate the payment information to ensure it
can cover the rentalCharge on a Reservation

Reservation which is accessed in this use case when the QueryTransaction
references the Reservation to attain the rentalCharge on the Reservation, or
if the payment information is invalid then the reservation deleted

with the OnlineCustomerWebBrowserInterface and forward requests to the
CustomerCoordinator

persistence and validation of the Customer’s payment information that they
enter in the system

Coordinator and persists QueryTransactions and associates them to
Reservations
BRS-4: Swipe Payment Information
SwipeableCardReader: Since the in-store customer actor interacts with the

BRS to swipe their payment information, this external I/O device interface
object is needed to receive the payment information swiped by the in-store
customer and to display a color-coded light indicating whether or not the
payment went through
SwipeableCardReaderInterface: An I/O interface needed to interface with the

SwipeableCardReader to provide card data to the CustomerCoordinator

actor interacts with the BRS to provide a signature after they swipe their
payment information, this user interface object is needed to record that
signature and approve it

communicate with the BRS to validate payment information entered by the
user

payment information provided by the in-store customer
InStorePaymentInformation: This is an entity object needed to approve the

signature provided by the customer on the
InStoreCustomerTabletKeypadDisplayInterface
QueryTransaction: This is an entity object needed to maintain information

about the query transaction to validate the payment information to ensure it
can cover the rentalCharge on a Reservation

Reservation which is accessed in this use case when the QueryTransaction
references the Reservation to attain the rentalCharge on the Reservation

with the InStoreCustomerTabletKeypadDisplayInterface and forward
requests to the CustomerCoordinator

persistence and validation of the Customer’s payment information that they
swipe into the system

Coordinator and persists QueryTransactions and associates them to
Reservations
BRS-5: Cancel Reservation

actor interacts with the BRS to cancel a reservation, this user interface
customers for input

interacts with the BRS to cancel a reservation, this user interface object is
needed to receive commands from customers and prompt customers for
input

communicate with the BRS to process the cancellation charge fee requested
by the BRS

reservation and mark it as canceled in this use case
SystemPrices: This is an entity object needed to maintain information about

the extra cancellation fee charged when a reservation is cancelled
PaymentTransaction: This is an entity object needed to maintain information

about the payment transaction that occurs when a customer cancels a
reservation and a cancellation fee is charged to their payment information (if
applicable)

payment information so that it can be charged when the reservation is
canceled or not

with the
InStoreCustomerTabletKeypadDisplayInterface/OnlineCustomerWebBrowserI

cancellation request made by the Customer

Coordinator and to mark a reservation as cancelled
BRS-6: Return Bike

actor interacts with the BRS to mark the bike as returned (after physically
returning it), this user interface object is needed to receive commands from
customers and prompt customers for input

interacts with the BRS to mark the bike as returned (after physically
returning it), this user interface object is needed to receive commands from
customers and prompt customers for input

communicate with the BRS to charge payment information

about the payment transaction that occurs when a customer returns the bike
to charge the payment information with the totalPaymentAmount

completed Reservation which is accessed in this use case when the
PaymentTransaction references the Reservation to attain all of the charges
on the Reservation

payment information so that it can be charged when the bike is returned
Bike: This is an entity object needed to maintain information about the bike
that is being returned so that the bike can temporarily be set to “out of
service” until it is inspected by an employee

with the
InStoreCustomerTabletKeypadDisplayInterface/OnlineCustomerWebBrowserI

return bike request made by the customer

Coordinator and to return a bike
BikeInventoryService: This is a service that interacts with the

CustomerCoordinator to take a bike out of service since it needs to be
inspected by an Employee first before it can show up in an Inventory search
again
BRS-7: Process Bike Return

EmployeeMobileWebDeviceKeypadDisplayInterface: Since the employee
actor interacts with the BRS to process the bike return, this user interface
object is needed to receive commands from the employee and prompt the
employee for input

communicate with the BRS to refund a partial late fee to the customer’s
payment information, if applicable
Reservation: This is an entity object needed to maintain information about

the reservation that the Employee can record notes on while processing the
bike return
Bike: This is an entity object needed to maintain information about the bike
that is being inspected by the employee, and can be put back in service by
the Employee after its inspected

about the payment transaction that occurs when an employee reduces the
late fee

payment information so that it can be refunded if the employee actor reduces
the late fee
EmployeeInteraction: This is a user interaction interface needed to interface

with the IEmployeeMobileWebDeviceKeypadDisplayInterface and forward
requests to the EmployeeCoordinator
EmployeeCoordinator: This is a coordinator object needed to coordinate the

process of a bike return request made by an employee
ReservationService: This is a service that interacts with the

EmployeeCoordinator to allow an employee to make maintenance or rental
problem notes on a Reservation

EmployeeCoordinator to update a bike’s “isInService” value after the
employee is done inspecting it
BRS-8: Set Charge
ManagerMobileWebDeviceKeypadDisplayInterface: Since the manager actor

interacts with the BRS to set the system prices, this user interface object is
needed to receive commands from the manager and prompt the manager for
input
SystemPrices: This is an entity object needed to maintain information about

the different charges in the system (reservation change charge and
reservation cancellation charge)
ManagerInteraction: This is a user interaction interface needed to interface

with the ManagerMobileWebDeviceKeypadDisplayInterface and forward
requests to the ManagerCoordinator
ManagerCoordinator: This is a coordinator object needed to coordinate the

setting of a system price charge in the system
SystemManagementService: This is a service that interacts with a

ManagerCoordinator to allow the persistence of a system-wide price
BRS-9: Set Bike Rental Rate

interacts with the BRS to set the bike rental rates, this user interface object
is needed to receive commands from the manager and prompt the manager
for input
Bike: This is an entity object needed to maintain information about the rental
price of a bike that is adjusted by the manager in this use case
Inventory: This is an entity object needed to perform a batch update of rental

price on all bikes that match the bike type selected by the manager


setting of a bike rental rate

ManagerCoordinator to perform rentalRate updates on all Bikes in the
Inventory when requested
BRS-10: Adjust Inventory

interacts with the BRS to adjust the inventory by adding and removing bikes
to the system, this user interface object is needed to receive commands
from the manager and prompt the manager for input
Bike: This is an entity object needed to maintain information about

describing a new bike added to the inventory
Inventory: This is an entity object needed to maintain information about what

bikes are present in the inventory


adding and removing of bikes in the system
BikeInventoryService: This is a service that perform and persist updates on

the Inventory object to add and remove bikes from the system
BRS-11: Generate Summary Report
AdministratorMobileWebDeviceKeypadDisplay: Since the administrator

interacts with the BRS to generate a summary report, this user interface
object is needed to receive commands from the administrator and prompt the
administrator for input
Inventory: This is an entity object needed to maintain information about the

collection of bikes in the inventory which the BRS analyzes when generating
the summary report
AdministratorInteraction: This is a user interaction interface needed to

interface with the AdministratorMobileWebDeviceKeypadDisplay and forward
requests to the AdministratorCoordinator
AdministratorCoordinator: This is a coordinator object needed to coordinate

the generation of a summary report across the system
ReservationService: This is a service that provides a reservation history for

all of the bikes in the system
BikeInventoryService: This is a service that retrieves all bikes in the system

that are used in the summary report
BRS-12: Generate Individual Bike Report
AdministratorMobileWebDeviceKeypadDisplay: Since the administrator

interacts with the BRS to generate an individual bike report, this user
interface object is needed to receive commands from the administrator and
prompt the administrator for input
Reservation: This is an entity object needed to maintain information about

the rental/reservation history of the bike so that the BRS can include this
history and rental notes when generating the individual bike report
AdministratorInteraction: This is a user interaction interface needed to

interface with the AdministratorMobileWebDeviceKeypadDisplay and forward
requests to the AdministratorCoordinator
AdministratorCoordinator: This is a coordinator object needed to coordinate

the generation of an individual bike report across the system
ReservationService: This is a service that provides a reservation history for a

selected bike in the system, including all notes from all reservations made
with that bike
BikeInventoryService: This is a service that retrieves all bikes in the system

so that the Administrator can select a bike for a report
Inventory: This is an entity object that provides the BikeInventoryService a

collection of bikes in the system
Sequence Diagrams
Note: Please zoom in to 200% or more to view all sequence diagrams
BRS-1a: Search Inventory (Online Customer)

BRS-1b: Search Inventory (In-Store Customer)
BRS-2a: Select Bike (Online Customer)
BRS-2b: Select Bike (In-Store Customer)
BRS-3: Enter Payment Information (Online Customer)
BRS-4: Swipe Payment Information (In-Store Customer)
BRS-5a: Cancel Reservation (Online Customer)
BRS-5b: Cancel Reservation (In-Store Customer)
BRS-6a: Return Bike (Online Customer)
BRS-6b: Return Bike (In-Store Customer)
BRS-7: Process Bike Return
BRS-8: Set Charge
BRS-9: Set Bike Rental Rates
BRS-10: Adjust Inventory
BRS-11: Generate Summary Reports
BRS-12: Generate Individual Bike Report
Works Cited
Gomaa, H. (2011). Software Modeling and Design. Cambridge, NY: Cambridge

University
Press.
Stephens, R. (2015). Beginning Software Engineering. Indianapolis, IN: John Wiley &
Sons.

Software Design Document: Bike Reservation System

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Software Design Document: Bike Reservation System

Caricato da

Copyright:

Formati disponibili

Software Design Document

Golden Bike Shop:

February 7th, 2020

• A customer can only have one credit card on file at a time

UML Use Case Diagram

Note: Please zoom in to 200% or more to view.

Use Case Name: Search Inventory

Use Case Id: BRS-1

Primary Actor(s): Customer

Secondary Actor(s): ---

Brief Description: Customer searches the inventory of the bike shop

Preconditions: Customer navigates to the website of the BRS

Post Conditions: The customer search results are displayed.

Alternative Flows and ---

Source: Golden Bike Shop Case Study

Use Case Id: BRS-2

Primary Actor(s): Customer

Secondary Actor(s): ---

Brief Description: The customer selects a bike to reserve.

Preconditions: The customer has performed an inventory search filtered by the

Flow of Events: 1. The customer selects a date range.

Alternative Flows and ---

Assumptions Once a bike is selected, it is marked unavailable in the system.

Source: Golden Bike Shop Case Study

Use Case Name: Enter Payment Information

Use Case Id: BRS-3

Primary Actor(s): Online Customer

Secondary Actor(s): External Payment System

Non-behavioral The external payment system must be available 24/7 to validate

Assumptions The online customer is reserving the bike ahead of time,

Source: Golden Bike Shop Case Study

Use Case Id: BRS-4

Primary Actor(s): In-Store Customer

Secondary Actor(s): External Payment System

Brief Description: The in-store customer swipes their payment information

Non-behavioral The swipe-to-pay feature needs to be available during business

Assumptions The in-store customer is reserving the bike in the store,

Source: Golden Bike Shop Case Study

Use Case Id: BRS-5

Primary Actor(s): Customer

Secondary Actor(s): ---

Brief Description: The customer cancels a reservation.

Preconditions: The customer has made a reservation.

Flow of Events: 1. The customer cancels a reservation.

Alternative Flows and 1. The customer cancels a reservation.

Source: Golden Bike Shop Case Study

Use Case Id: BRS-6

Primary Actor(s): Customer

Secondary Actor(s): External Payment System

Flow of Events: 1. Bike is physically turned in by the customer

Post Conditions: ---

Alternative Flows and ---

Assumptions The customer shows up for the bike return day.

Issues: If the bike is returned damaged, late or not at all.

Source: Golden Bike Shop Case Study

Use Case Id: BRS-7

Primary Actor(s): Employee

Secondary Actor(s): External Payment System

Flow of Events: 1. Employee checks the BRS and sees a customer

Alternative Flows and ---

Non-behavioral Bike is in acceptable condition to be rented out.

Assumptions Bike has little if any damage.

Source: Golden Bike Shop Case Study