Software Design Document
For
Golden Bike Shop:
Bike Reservation System
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
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
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
Alternative Flows and ---
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: ---
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
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.
3. The external payment system validates the payment
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: ---
Source: Golden Bike Shop Case Study
Use Case Name: Swipe Payment Information
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
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.
3. The external payment system validates the payment
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.
3. The external payment system validates the payment
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: ---
Source: Golden Bike Shop Case Study
Use Case Name: Cancel Reservation
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.
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: ---
Source: Golden Bike Shop Case Study
Use Case Name: Return Bike(s)
Use Case Id: BRS-6
Primary Actor(s): Customer
Secondary Actor(s): External Payment System
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
Alternative Flows and ---
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.
Source: Golden Bike Shop Case Study
Use Case Name: Process Bike Return
Use Case Id: BRS-7
Primary Actor(s): Employee
Secondary Actor(s): External Payment System
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
Alternative Flows and ---
Directions:
Non-behavioral Bike is in acceptable condition to be rented out.
requirements:
Assumptions Bike has little if any damage.
Issues: ---
Source: Golden Bike Shop Case Study
Use Case Name: Set Charge
Use Case Id: BRS-8
Primary Actor(s): Manager
Secondary Actor(s): External Payment System
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: ---
Source: Golden Bike Shop Case Study
Use Case Name: Set Bike Rental Rate
Use Case Id: BRS-9
Primary Actor(s): Manager
Secondary Actor(s): ---
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
Alternative Flows and ---
Directions:
Non-behavioral ---
requirements:
Assumptions ---
Issues: ---
Source: Golden Bike Shop Case Study
Use Case Name: Adjust Inventory
Use Case Id: BRS-10
Primary Actor(s): Manager
Secondary Actor(s): ---
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: ---
Source: Golden Bike Shop Case Study
Use Case Name: Generate Summary Report
Use Case Id: BRS-11
Primary Actor(s): Administrator
Secondary Actor(s): ---
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
Alternative Flows and ---
Directions:
Non-behavioral ---
requirements:
Assumptions ---
Issues: ---
Source: Golden Bike Shop Case Study
Use Case Name: Generate Individual Bike Report
Use Case Id: BRS-12
Primary Actor(s): Administrator
Secondary Actor(s): ---
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
Alternative Flows and ---
Directions:
Non-behavioral Bike needs to be present in inventory (even if decommissioned)
requirements:
Assumptions ---
Issues: ---
Source: Golden Bike Shop Case Study
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:
Attribute Name Data Type Description
bikes Bike[ ] The collection of bikes
that is in the inventory
3. Administrator class maintains information about an administrator that includes the following
attributes:
Attribute Name Data Type Description
administratorId Integer Administrator unique ID
administratorName String Name of the
administrator
4. Manager class maintains information about a manager that includes the following attributes:
Attribute Name Data Type Description
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:
Attribute Name Data Type Description
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:
Attribute Name Data Type Description
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:
Attribute Name Data Type Description
employeeId Integer Employee unique ID
employeeName String Name of the employee
8. Customer class maintains information about a customer that includes the following attributes:
Attribute Name Data Type Description
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:
Attribute Name Data Type Description
paymentInfoId Integer Unique ID for the
customer payment
information
cardType String Type of card (ex. Visa)
cardNumber String Credit Card number
Attribute Name Data Type Description
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:
Attribute Name Data Type Description
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:
Attribute Name Data Type Description
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:
Attribute Name Data Type Description
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:
Attribute Name Data Type Description
paymentTransactionId Integer Unique ID for the
payment transaction
totalPaymentAmount Real Total payment amount,
includes the
rentalCharge +
additionalCharge
captured from the
referenced Reservation
Attribute Name Data Type Description
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
InStoreCustomerTabletKeypadDisplayInterface: Since the in-store customer
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
OnlineCustomerWebBrowserInterface: Since the online customer 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
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)
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
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
OnlineCustomerWebBrowserInterface: Since the online customer actor
interacts with the BRS to enter their payment information, this user interface
object is needed to receive commands from customers and prompt
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: This is an entity object needed to maintain information about a
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
CustomerInteraction: This is a user interaction interface needed to interface
with the OnlineCustomerWebBrowserInterface and forward requests to the
CustomerCoordinator
CustomerCoordinator: This is a coordinator object needed to coordinate the
persistence and validation of the Customer’s payment information that they
enter in the system
ReservationService: This is a service that interacts with the Customer
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
InStoreCustomerTabletKeypadDisplayInterface: Since the in-store customer
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
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 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: This is an entity object needed to maintain information about a
Reservation which is accessed in this use case when the QueryTransaction
references the Reservation to attain the rentalCharge on the Reservation
CustomerInteraction: This is a user interaction interface needed to interface
with the InStoreCustomerTabletKeypadDisplayInterface and forward
requests to the CustomerCoordinator
CustomerCoordinator: This is a coordinator object needed to coordinate the
persistence and validation of the Customer’s payment information that they
swipe into the system
ReservationService: This is a service that interacts with the Customer
Coordinator and persists QueryTransactions and associates them to
Reservations
BRS-5: Cancel Reservation
InStoreCustomerTabletKeypadDisplayInterface: Since the in-store customer
actor interacts with the BRS to cancel a reservation, 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 cancel a reservation, this user interface object is
needed to receive commands from customers and prompt customers for
input
ExternalPaymentSystemInterface: This system interface object is needed to
communicate with the BRS to process the cancellation charge fee requested
by the BRS
Reservation: This is an entity object needed to maintain information about a
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)
CustomerPaymentInformation: This is an entity object needed to maintain
payment information so that it can be charged when the reservation is
canceled or not
CustomerInteraction: This is a user interaction interface needed to interface
with the
InStoreCustomerTabletKeypadDisplayInterface/OnlineCustomerWebBrowserI
nterface and forward requests to the CustomerCoordinator
CustomerCoordinator: This is a coordinator object needed to coordinate the
cancellation request made by the Customer
ReservationService: This is a service that interacts with the Customer
Coordinator and to mark a reservation as cancelled
BRS-6: Return Bike
InStoreCustomerTabletKeypadDisplayInterface: Since the in-store customer
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
OnlineCustomerWebBrowserInterface: Since the online customer 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
ExternalPaymentSystemInterface: This system interface object is needed to
communicate with the BRS to charge payment information
PaymentTransaction: This is an entity object needed to maintain information
about the payment transaction that occurs when a customer returns the bike
to charge the payment information with the totalPaymentAmount
Reservation: This is an entity object needed to maintain information about a
completed Reservation which is accessed in this use case when the
PaymentTransaction references the Reservation to attain all of the charges
on the Reservation
CustomerPaymentInformation: This is an entity object needed to maintain
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
CustomerInteraction: This is a user interaction interface needed to interface
with the
InStoreCustomerTabletKeypadDisplayInterface/OnlineCustomerWebBrowserI
nterface and forward requests to the CustomerCoordinator
CustomerCoordinator: This is a coordinator object needed to coordinate the
return bike request made by the customer
ReservationService: This is a service that interacts with 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
ExternalPaymentSystemInterface: This system interface object is needed to
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
PaymentTransaction: This is an entity object needed to maintain information
about the payment transaction that occurs when an employee reduces the
late fee
CustomerPaymentInformation: This is an entity object needed to maintain
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
BikeInventoryService: This is a service that interacts with the
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
ManagerMobileWebDeviceKeypadDisplayInterface: Since the manager actor
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
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 bike rental rate
BikeInventoryService: This is a service that interacts with the
ManagerCoordinator to perform rentalRate updates on all Bikes in the
Inventory when requested
BRS-10: Adjust Inventory
ManagerMobileWebDeviceKeypadDisplayInterface: Since the manager actor
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
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
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
State Dependent Use Case: BRS-4 Swipe Payment
Information
BRS-4: Use Case Diagram (taken from the Use Case section above)
BRS-4: State Chart Model
BRS-4: State Dependent Control Object Sequence Diagram
Please zoom in to 200% or more to view.
Activity Diagram
BRS-7: Process Bike Return Activity Diagram
Actor: Employee
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.