This appendix contains excerpts from a completed use-case model intended to complement the smaller examples embedded throughout the book.
It does not include the complete set of artifacts discussed in the book. In fact it does not contain
A complete use-case model as these often run to hundreds of pages
A complete Vision document as these are typically 10 to 20 pages in length
A complete Supplementary Specification
A glossary and domain model
Templates for the documents
A style guide based on the guidance contained in the book
All of these things are available from www.usecasemodeling.com in a more readily useable and interactive, electronic format.
The examples in this section are based on the Automated Teller Machine model that was fleshed out in Chapter 9, Writing Use-Case Descriptions: Revisited. The examples show the final form of the completed use cases and may differ slightly from the evolutionary fragments found in Chapter 9.
In this example we provide edited highlights of the use-case model for an Automated Teller Machine (ATM). We only include the following elements of the model to prevent this appendix from running to literally hundreds of pages and taking up a disproportionate amount of the book:
A cut down use-case model survey to provide an overview of the entire ATM model.
The full Withdraw Cash use case to provide an example of what a completed use case would look like and demonstrate the level of detail required for a fully described use case. [1]
The full Authenticate Customer use case to provide an example of an included use case. This use case is included by 4 of the use cases in the model.
An extract from the project’s glossary to support the use-case descriptions.
The full model can be accessed in a navigable, electronic format at www.usecasemodeling.com, which we hope you will find more useful than the inclusion of another 11 use-case descriptions in this appendix.
This set of suggested solutions to the classic ATM problem is inspired by Swedish, American, Australian, Canadian, and British ATM systems. The authors of this example have never built a real ATM system. They have just used their knowledge as ATM Customers and use-case authors. The point of this set of solutions is to show what a solution may look like and the level detail that should be used when describing use cases.
A lot of the ideas in this example come from training courses run in Aus-tralia and England that involved developers who actually built bank applications. BEWARE: THIS IS NOT A REAL SYSTEM! The supporting definitions and descriptions of ATM and Bank System dialogues are all fictitious. The purpose of the examples is not to provide an accurate use-case model for an ATM but to provide examples of fully complete use-case descriptions.
|
For |
Current Account-Holding Customers |
|
Who |
Require instant access to their account details and the funds they contain |
|
The |
Super ATM is an automated teller machine |
|
That |
Provides the ability to perform simple bank transactions (such as withdrawing or depositing funds, or transferring funds between accounts) |
|
Unlike |
Accessing funds and details over the branch counter |
|
Our product |
Is available 24 hours a day and does not require the assistance of a bank teller |
Figure A-1 shows all the actors in the ACME Super ATM use-case model. The brief descriptions of the actors are given in the subsections that follow the figure.
The Customer conducts transactions at the ATM. He or she may withdraw funds, check account balances, deposit funds, and transfer amounts between accounts. A Customer is created when a person opens an account at an affiliated financial institution.
The Bank System provides services to the ATM. It is responsible for verifying Customers, authorizing transactions, and supplying the ATM with information about the Customers’ accounts. The Bank System acts as a gateway to the Customer’s bank.
The Service Administrator is responsible for ensuring that a set of ATMs meets required service levels and for installing and running advertising cam-paigns.
The Security Administrator monitors the ATM for security breaches such as the fraudulent use of cards and any attempts to physically break into the ATM.
The ATM Engineer is responsible for the physical maintenance of the ATM, refilling the machine with cash and paper, clearing any mechanical problems, and undertaking the on-site configuration of the machine.
The ATM Operator is responsible for the operation of the ATM, analyzing the performance of the system, reconciling the accounts between the ATM and the Bank System, and updating the system configuration. The ATM Operator may be accessing the machine by directly connecting to the machine or remotely over a networked communications link.
Figure A-2 shows the primary use cases from the ACME Super ATM use-case model. The brief descriptions of the use cases are given in the subsections that follow.
* The secondary actors and any related use cases are suppressed from the diagram to aid readability and allow the diagram to illustrate the purpose of the ACME Super ATM.
Figure A-2. The primary use cases for the ACME Super ATM*
This use case describes how a Customer uses an ATM to withdraw money from a bank account.
The use case describes how a Customer uses the ATM to deposit money into an account. The Customer places the money or checks into an envelope and inserts the envelope into the ATM. The envelopes are securely stored within the machine until the ATM engineer picks them up at a later date as part of the machine’s daily maintenance. Note: The ATM does not actually credit the amount deposited to the Customer’s account.
This use case describes how a Customer uses the ATM to transfer money to and from an account.
This use case describes how a Customer uses the ATM to manage his or her account: viewing balances and mini-statements, requesting full statements, and ordering account-related products such as check books and paying-in books.
This use case describes how the system responds when someone attempts to break into or vandalize the machine. [2]
Figure A-3 shows the supporting use cases from the ACME Super ATM use-case model. The brief descriptions of the use cases are given in the subsections that follow the figure.
* Again the secondary actors and any related use cases are suppressed from the diagram to aid readability.
Figure A-3. The supporting use cases for the ACME Super ATM*
This use case describes how an ATM Engineer keeps the ATM running on a day-to-day basis by refilling the machine with cash, emptying the machine of any deposits, refilling the machine with receipt paper, and generally servicing the hardware.
This use case describes how an ATM Engineer sets up or reconfigures the ATM for use at a specific location, with a specific Bank System, and with a set of financial institutions.
This use case describes how an ATM Engineer uses the ATM to run a set of diagnostic routines to ensure that it is functioning correctly.
This use case describes how an ATM Operator can interrogate the ATM’s internal records to analyze performance and diagnose problems.
This use case describes how an ATM Operator uses the ATM to reconcile any differences between its transaction history and that of the Bank System. Errors can cause the ATM and the Bank System to have different understandings of how much money has been dispensed or collected.
This use case describes how an ATM Operator can update the tunable parameters of the system’s configuration without taking the ATM out of service. Tunable parameters include, among others, the set of Banks supported, the maximum withdrawal amount, the maximum deposit amount, and the set of services available.
This use case describes how a Service Administrator can use the ATM to run an advertising campaign that displays advertisements when the machine is idle and during the performance of the other use cases. This use case is provided on behalf of the Marketing Department, one of the major stakeholders in the Super ATM project.
Brief Description
This use case describes how a Bank Customer uses an ATM to withdraw money from a bank account.
Use-Case Diagram
See Figure A-4.
Preconditions
The bank Customer must possess a bank card.
The network connection to the Bank System must be active.
The system must have at least some cash that can be dispensed.
The cash withdrawal service option must be available.
Basic Flow
{Insert Card}
The use case begins when the actor Customer inserts a bank card into the card reader on the ATM.
The system allocates an ATM session identifier to enable errors to be tracked and synchronized between the ATM and the Bank System.
{Read Card}
The system reads the bank card information from the card.
{Authenticate Customer}
Include use case Authenticate Customer to authenticate the use of the bank card by the individual using the machine.
{Select Withdrawal}
The system displays the different service options that are currently available on the machine.
The Customer selects to withdraw cash.
{Select Amount}
The system prompts for the amount to be withdrawn by displaying the list of standard withdrawal amounts.
The Customer selects an amount to be withdrawn.
{Confirm Withdrawal}
Perform Assess Funds on Hand.
Perform Conduct Transaction.
{Eject Card}
The system ejects the Customer’s bank card.
The Customer takes the bank card from the machine.
{Dispense Cash}
The system dispenses the requested amount to the Customer.
The system records a transaction log entry for the withdrawal.
{Use Case Ends}
The use case ends.
Alternative Flows
5.1 Specialist Withdrawal Facilities
5.1.1 Handle the Withdrawal of a Non-Standard Amount
At {Select Amount} if the Customer requires a non-standard amount,
The system asks the Customer for the required amount indicating that the amount entered must be a multiple of the smallest denomination note held and must be below the amount of the ATM’s withdrawal limit and the amount of currency held by the machine.
The Customer enters the desired amount.
Resume the basic flow at {Confirm Withdrawal}.
5.2 Card Handling
5.2.1 Handle Card Jam
At {Insert Card}, {Eject Card}, or {Retrieve Card}, if the bank card jams in the card reader,
{Emergency Eject Card}
The system attempts to eject the card.
If the card ejection is successful, the system informs the Customer
That the card may be faulty
That he or she should contact the Bank to get a replacement card
That the Customer should take the bank card from the machine
The use case resumes the basic flow at {Use Case Ends}.
{Emergency Confiscation}
If the emergency ejection fails, the system attempts to retrieve the card and add it to the confiscated cards.
If the card retrieval is successful, the system
Captures a 10-second video image of the Customer.
Creates an event log entry to record the fact that a card has been retained because it became stuck in the card reader. The event log entry includes the video image and the current bank card information (excluding the PIN) if it is available.
Sends the event log entry to the Bank System and the Service Administrator to inform them that a card has been retained because it became stuck in the card reader.
Informs the Customer that the card cannot be returned because of a technical error and that he or she should contact the Service Organization for the return of the card.
{Card Jammed}
If the card could not be ejected or retrieved, the system,
Captures a 10-second video image of the Customer.
Creates an event log entry to record the fact that a card is jammed in the card reader. The event log entry includes the video image and the current bank card information (excluding the PIN) if it is available.
Sends the event log entry to the Bank System and the Service Administrator to inform them that a card has become jammed in this ATM.
Informs the Customer that the card cannot be returned because of a technical error and that he or she should contact the Service Organization for the return of the card.
If the card is still jammed, the system Performs Service Shutdown to shutdown all service options and end the use case.
5.2.2 Handle Unreadable Bank Card
At {Read Card} if the system cannot read all the bank card information,
The system captures a 10-second video image of the Customer.
The system creates an event log entry to record the fact that the card could not be read. The event log entry includes the video image and any bank card information (excluding the PIN) that it managed to read.
The system informs the Customer that the card cannot be read and that he or she should contact the bank to have the card checked.
{Eject Card}
The system ejects the Customer’s bank card.
The Customer takes the bank card from the machine.
The use case resumes the basic flow at {Use Case Ends}.
5.2.3 Handle Invalid Card
At {Read Card} if the system does not support the financial institution associated with the card or cannot identify the financial institution associated with card,
The system captures a 10-second video image of the Customer.
The system creates an event log entry to record the fact that an attempt was made to use the ATM using an invalid card. The event log entry includes the video image and the bank card information (excluding the PIN).
The system informs the Customer that the card cannot be used in this ATM.
{Eject Card}
The system ejects the Customer’s bank card.
The Customer takes the bank card from the machine.
The use case resumes the basic flow at {Use Case Ends}.
5.2.4 Handle Card Left Behind By Customer
At {Eject Card} or {Emergency Eject Card} if the bank card is not removed from the ATM within 30 seconds,
The system beeps to alert the Customer.
If the card has still not been removed within a minute of the alert being sounded, then the system
{Retrieve Card}
Retrieves the card and adds it to the confiscated cards.
{Adjust the Account Balances}
If there are funds still to be dispensed, then the system Performs Handle Transaction Adjustments to put the money back into the account as it will not now be dispensed.
{Record the Event}
The system creates an event log entry to record the fact that the card was left behind in the ATM. The event log entry includes the bank card information (excluding the PIN).
The system sends the event log entry to the Bank System to inform it that the card has been left in the ATM.
The system turns off the alert.
The use case resumes the basic flow at {Use Case Ends}.
5.3 Receipt Handling
5.3.1 Offer Receipt Handling to the Customer
At {Select Withdrawal} if the ATM is not out of paper,
The system offers the Customer the facility to have a receipt printed for the transaction.
The Customer indicates whether a receipt is required.
The use case resumes from the place where it was interrupted.
5.3.2 Withdraw the Receipt Facility
At {Select Withdrawal} if the ATM is out of paper or the paper is jammed,
The system informs the Customer that the facility to have a receipt printed for the transaction is currently unavailable.
The use case resumes from the place where it was interrupted.
5.3.3 Handle the Printing of Receipts
At {Dispense Cash} if a receipt was requested,
The system prints a withdrawal receipt.
If the ATM does not have sufficient paper to print the receipt or the printer jams, the system
Creates an event log entry to record the fact that the receipt printing is out of order. The event log entry includes the bank card information (excluding the PIN).
Sends the event log to the Bank System and the Service Administrator to inform them of the failure and its reason (out of paper or paper jam).
Informs the Customer that the receipt cannot be printed.
Displays the withdrawal receipt information to enable the Customer to take a manual record of the transaction.
Asks the Customer to ackowledge the receipt information has been displayed.
Displays the receipt information for 2 minutes or until it is acknowledged by the Customer.
The system beeps to alert the Customer that the receipt information is available.
The use case resumes from the place where it was interrupted.
5.4 Error Handling
5.4.1 Handle Authentication Failures
At {Authenticate Customer} if the bank card is not authenticated, then
Unless the card has been deliberately retained the card is returned to the Customer:
{Eject Card}
The system ejects the Customer’s bank card.
The Customer takes the bank card from the machine.
The use case resumes the basic flow at {Use Case Ends}.
5.4.2 Handle the Bank Not Approving the Withdrawal
At {Validate the Withdrawal} if the Bank System responds with a withdrawal rejection, then
If the Bank System rejected the withdrawal because there are not enough funds in the account the system, the system
Informs the Customer that the withdrawal has been rejected because the account does not have sufficient funds
If the Bank System rejects the withdrawal for any other reason, the system
Informs the Customer that the withdrawal has been rejected by the Customer’s Bank
Advises the Customer to contact the Bank for further details
The system records a transaction log entry for the transaction including the reason given for the transaction’s rejection.
Resume the use case from {Select Withdrawal}
5.4.3 Handle Cash Dispensing Errors
At {Dispense Cash} if the full amount cannot be dispensed (notes might be rejected by, or get stuck in, the counting and dispensing device), then
The system records an event log entry to record the fact that there has been a dispensing error. The event log entry includes the bank card information (excluding the PIN) and the details of the cause of the dispensing error.
The system sends the event log entry to the Service Administrator and the Bank System to inform them that the ATM is no longer able to dispense cash.
The system disables the cash withdraw service option.
The system records a transaction log entry for the transaction including both the amount that should have been dispensed and the amount that was actually dispensed.
Perform Handle Transaction Adjustments to balance the ATM and the Bank System.
The use case resumes the basic flow at {Use Case Ends}.
5.4.4 Handle Money Left Behind By Customer
At {Dispense Cash} if the cash is not removed from the ATM within 30 seconds,
The system beeps to alert the Customer.
If the cash has still not been removed within a minute of the alert being sounded, then the system
Retrieves the cash, checking the amount that has been left behind.
Creates an event log entry to record the fact that cash has been left uncollected. The event log entry includes the bank card information (excluding the PIN), the amount of cash retrieved, and the amount of cash dispensed.
Records a transaction log entry for the transaction including both the amount that should have been taken and the amount that was actually taken.
Performs Handle Transaction Adjustments to balance the ATM and the Bank System.
Turns off the alert.
The use case resumes the basic flow at {Use Case Ends}.
5.4.5 Handle Running Out of Critical Resources
At {Use Case Ends} if the system does not have the capacity to log any more events or log any more transactions, then the system
Performs Service Shutdown to shutdown all service options and end the use case
5.4.6 Handle Running Out of Cash
At {Use Case Ends} if the system has no more funds to dispense,
The system removes Withdraw Cash from the list of available service options.
The system creates an event log entry to record the fact that the ATM has run out of cash.
The system sends the event log entry to the Service Administrator and the Bank System to inform them that the ATM is no longer able to dispense cash.
The use case resumes from the place where it was interrupted.
5.4.7 Handle Security Breaches
At any time when an attempt to gain physical access to the currency dispenser is detected,
The system starts to video the Customer.
The system creates an event log entry to record the fact that the ATM has detected an attack.
The system sends the event log entry to the Security Administrator, the Service Administrator, and the Bank System to inform them that the ATM is being attacked.
If the card has not yet been ejected, the card is confiscated.
If a withdrawal has been approved but the cash has not yet been dispensed, the transaction is canceled.
The system creates an event log entry to record the actions taken. The event log entry includes the bank card information (excluding the PIN).
The system sends the event log entry to the Security Administrator, the Service Administrator, and the Bank System to inform them what action has been taken.
If a transaction was canceled, the system
Records a transaction log entry for the transaction including both the amount that should have been dispensed and the amount that was actually dispensed
Performs Handle Transaction Adjustments to balance the ATM and the Bank System
The Customer is informed that the card has been confiscated and the transaction ended.
The system saves the video recording with the session ID.
The use case resumes the basic flow at {Use Case Ends}.
5.4.8 Handle the Customer Quitting the Session
At any time if the Customer elects to quit the session,
{Tidy Up the Session}
The system stops the current transaction.
If the Customer quits after a withdrawal has been authorized but before the cash has been dispensed, then the system
Records a transaction log entry for the transaction including both the amount that should have been dispensed and the amount that was actually dispensed
Performs Handle Transaction Adjustments to balance the ATM and the Bank System
{Eject Card}
The system ejects the Customer’s bank card.
The Customer takes the bank card from the machine.
The use case resumes the basic flow at {Use Case Ends}.
5.4.9 Handle the Customer Stopping Responding
At any time where a response from the Customer is requested, if no response is made within 30 seconds (this does not include removing the card or the cash when it is dispensed as each is explicitly handled by its own flows),
The system beeps to alert the Customer.
If there is still no reply within a minute of the alert being sounded, then the system
Confiscates the card.
Creates an event log entry to record that the card has been confiscated. The event log entry includes the bank card information (excluding the PIN).
Sends the event log entry to the Bank System to inform the Customer’s bank that the card has been confiscated.
If the event happens after a withdrawal has been authorized but before the cash has been dispensed, then the system
Records a transaction log entry for the transaction including both the amount that should have been dispensed and the amount that was actually dispensed
Performs Handle Transaction Adjustments to balance the ATM and the Bank System
Turns off the alert
The use case resumes the basic flow at {Use Case Ends}.
5.4.10 Handle Video Recording Failure
At any point in the flow of events where video is being recorded, if the video capture device fails or there is insufficient storage for the video images,
The system creates an event log entry to record the failure of the video system. The event log entry includes the type of failure (video storage full or video device failure).
The system sends the event log entry to the Service Administrator and the Bank System to inform them that the video system has failed.
The system turns off the video device to await the maintenance engineer. There is no need to disable the ATM as all functions can continue without the video being active.
The use case resumes from the point that the failure was detected.
5.4.11 Handle Transaction Log Failure
At any point in the flow of events where a transaction log is being recorded, if the log cannot be stored,
The system creates an event log entry to record the fact that transaction log has failed. The event log entry includes the current bank card information (excluding the PIN).
The system sends the event log entry to the Bank System and the Service Administrator to inform them that the transaction log is out of order.
If the event happens after a withdrawal has been authorized but before the cash has been dispensed, then the system
Sends the transaction log entry to the Bank System to cancel the withdrawal.
Creates an event log entry to record the fact that the transaction has been canceled. The event log entry includes the current bank card information (excluding the PIN), the fact that the transaction was a withdrawal, and the amount of the withdrawal.
The system informs the Customer that because of a technical problem the request could not currently be fulfilled.
{Eject Card}
The system ejects the Customer’s bank card.
The Customer takes the bank card from the machine.
{Shutdown All Customer Services}
Perform Service Shutdown to shutdown all Customer services and end the use case.
5.4.12 Handle Event Log Failure
If at any point in the use case the event log fails, the use case will continue to completion without logging any events. At the end of the use case, the customer services will be shutdown (see Handle Running Out of Critical Resources). For the details of how event log failures are handled by the system, see the Supplementary Specification.
5.5 Handle the Bank System Stopping Responding
At {Validate the Withdrawal} if the Bank System cannot be contacted or does not reply within the set communication time out period,
{Attempt to Reestablish Communications}
If the communications link has not failed, during this use case, more times than the communication retry number, then the system will attempt to contact the Bank System until it has completed the number of retry attempts indicated by the communication retry number.
If communication is reestablished, the flow is resumed at {Validate the Withdrawal}.
{Cancel the Withdrawal}
If there is still no response from the Bank System, the system creates an event log entry to record the failure of the communication link to the Bank System. The event log entry includes the type of failure.
The system sends the event log to the Service Administrator to inform it that communication with Bank System has been lost.
The system records a transaction log entry for the transaction including the fact that the withdrawal was not authorized because of loss of communications with the Bank System.
The system informs the Customer that the withdrawal has been rejected because the Bank System cannot be contacted.
{Eject Card}
The system ejects the Customer’s bank card.
The Customer takes the bank card from the machine.
{Resume the Basic Flow}
The use case resumes the basic flow at {Use Case Ends}.
5.5.1 Handle Loss of Connection to the Security Administrator or the Service Administrator
If at any time the system attempts to contact the Security Administrator or the Service Administrator and fails, the use case will still continue to completion. For the details of how these generic communications failures are handled by the system, see the Supplementary Specification.
Subflows
6.1 Assess Funds on Hand
The system determines whether it has sufficient funds on hand to dispense the requested amount.
The system checks to see if the total amount requested is greater than the amount on hand.
The system checks to see if the requested amount can be dispensed with the denominations on hand. Note that it is possible to have sufficient funds in total and still be unable to dispense funds. Consider the case in which the Customer has requested $35 but the system only has $40 in the form of two $20 bills.
If there are not sufficient funds on hand, the system
Informs the Customer that the amount requested is not available from the ATM.
Offers the Customer a choice of the nearest available amount(s). If the amount requested was rejected because the correct denomination notes were not available, then both the nearest amounts below and above that requested are offered. If the amount requested was rejected because it was higher than the amount of funds available, then the nearest amount below that requested is offered.
The Customer selects an amount to be withdrawn.
The flow of events resumes at the next step.
6.2 Conduct Withdrawal
{Validate the Withdrawal}
The system supplies the Bank System with the bank card information, the amount of the requested withdrawal, the ATM Session Identifier, and the transaction fee and asks the Bank System to approve the withdrawal.
The Bank System responds with a withdrawal acceptance to approve the withdrawal.
{Log the Authorization}
The system records a transaction log entry for the authorized withdrawal including the information that the cash is still to be dispensed.
{Return to Performing Flow}
Resume at the next step.
6.3 Service Shutdown
The ATM displays the fact that it is out of order and that no service options are available.
The system turns off the card reader to prevent the insertion of any more cards.
The system creates an event log entry to record the fact that the system has switched off all customer services. The event log entry includes the time of the of service shutdown. If the recording of the event log fails, the system just ignores it.
If they are still contactable, the system sends the event log entry to the Service Administrator and the Bank System to inform them that the ATM is out of order. If they are not available, the system continues to attempt to inform them of the current state of the system.
The use case ends.
6.4 Handle Transaction Adjustments
The system calculates the adjustment required by the Banking System for this withdrawal by subtracting the amount of cash dispensed from the amount approved for withdrawal.
The system informs the Bank System of the amount of the adjustment also specifying the bank card information and the ATM Session Identifier.
The Bank System accepts or rejects the adjustment.
The system records a transaction log entry for the adjustment indicating whether the transaction was accepted or rejected and including the Bank System’s response.
Resume at the next step.
Postconditions
The ATM has returned the card and dispensed the cash to the Customer, and the withdrawal is registered on the Customer’s account.
The ATM has returned the card to the Customer, and no withdrawal is registered on the Customer’s account.
The ATM has returned the card, but has not supplied the amount of cash registered as withdrawn from the Customer’s account; the discrepancy is registered on the ATM’s logs.
The ATM has kept the card, no withdrawal has registered on the Customer’s account, and the Customer has been notified where to contact for more information.
Public Extension Points
None
Special Requirements
9.1 Reliable Cash Dispensing
The ATM shall dispense the correct amount of cash in at least 99 percent of cash withdrawals.
Brief Description
This use case is included by other use cases. [3] It is used to authenticate that the individual using the ATM (the Customer) is authorized to use the inserted bank card and that the account associated with the bank card is active.
Use-Case Diagram
See Figure A-5.
Preconditions
The bank card has been inserted into the ATM.
The bank card information has been read successfully.
A Customer is in dialogue with the including use case.
The ATM Session ID has been created.
Basic Flow
{Validate Card Information}
The system sends the bank card information to the Bank System to confirm that the bank card and its associated account are active, that the card has not been reported stolen, and that the bank card information (including the PIN) read from the bank card is valid.
The system also sends the ATM ID and the ATM session identifier to the Bank System along with the bank card information.
The Bank System acknowledges that the bank card information is valid and that the card can be used.
{Validate User Identity}
The system prompts the Customer for the PIN.
The Customer enters the PIN.
The system checks that the entered PIN is identical to the PIN read from the bank card.
{PIN Validated}
{Use Case Ends}
Resume the including use case at the next step.
Alternative Flows
5.1 Handle No Communications With the Bank System
At {Validate Card Information} if the Bank System cannot be contacted or does not reply within the set communication time-out period,
And if the communications link has failed more times than the communication retry number, then the authentication attempt is aban-doned and basic flow is resumed at {Use Case Ends}.
The system will attempt to contact the Bank System until it has completed the number of retry attempts indicated by the communication retry number.
If communications are reestablished, the basic flow is resumed at
{Validate Card Information}.
If there is still no response from the Bank System, the system creates an event log entry to record the failure of the communications link to the Bank System. The event log entry includes the type of failure.
The system sends the event log to the Service Administrator to inform it that communication with Bank System has been lost.
Resume the basic flow at {Use Case Ends}.
5.2 Handle No Communications With the Customer’s Bank
At {Validate Card Information} if the Bank System reports that the Customer’s Bank cannot be contacted,
The system creates an event log entry to record the fact that the Customer’s Bank was unavailable. The event log entry includes the bank card information (excluding the PIN).
The system informs the Customer that communication with the Bank is not possible and that he or she should try again later.
Resume the basic flow at {Use Case Ends}.
5.3 Handle Inactive Card or Account
At {Validate Card Information} if the Customer’s Bank reports that the card or its associated account are inactive,
The system creates an event log entry to record the fact that the Customer’s account was inactive. The event log entry includes the bank card information (excluding the PIN).
The system informs the Customer that the account associated with the card is not active and that he or she should contact the Bank for more information.
Resume the basic flow at {Use Case Ends}.
5.4 Handle Stolen Bank Card
At {Validate Card Information} if the Bank System reports that the card has been stolen:
The system
Confiscates the card.
Captures a 10-second video image of the Customer.
Creates an event log entry to record the fact that a stolen card has been used. The event log entry includes the video image and the current bank card information (excluding the PIN).
Sends the event log entry to the Security Administrator, the Bank System, and the Service Administrator to inform them that a stolen card is being used.
Continues to video the Customer.
The system delays for 5 minutes indicating that the system is busy (the system should try to keep the Customer at the machine for as long as possible).
After the delay the system reports to the Customer that
The card has been confiscated.
He or she should contact the bank with any questions.
The system stops the video and creates an event log entry to store the captured images. The event log entry includes the video image and the current bank card information (excluding the PIN).
Resume the basic flow at {Use Case Ends}.
5.5 Handle Invalid Bank Card Information
At {Validate Card Information} if the Bank System reports that the bank card information is not valid,
The system
Captures a 10-second video image of the Customer.
Creates an event log entry to record the fact that the card information was invalid. The event log entry includes the video image and the current bank card information (excluding the PIN).
Sends the event log entry to the Security Administrator, the Bank System, and the Service Administrator to inform them that a card with invalid bank card information is being used.
The system reports to the Customer that
The card could not be read.
He or she should contact the bank with any questions.
Resume the basic flow at {Use Case Ends}.
5.6 Handle Correct PIN Not Entered
At {PIN Validated} if the PIN has not been entered correctly,
The system informs the Customer that the PIN has been entered incorrectly.
If the Customer has had fewer than 3 attempts at entering the PIN, the system informs the Customer that he or she should have another attempt.
If this is the Customer’s third attempt, the system
Confiscates the card.
Captures a 10-second video image of the Customer.
Creates an event log entry to record the fact that the Customer failed to get the PIN number correct in 3 attempts. The event log entry includes the video image and the current bank card information (excluding the PIN).
Sends the event log entry to the Bank System and the Service Administrator to inform them that a Customer’s bank card was confiscated because of the Customer’s failure to enter the PIN correctly.
The system reports to the Customer that
The card has been confiscated because the PIN number was not entered correctly.
He or she should contact the Service Organization to retrieve the card.
He or she should contact the bank with any questions.
Resume the basic flow at {Use Case Ends}.
Postconditions
The Customer has been authorized to use the card.
The Customer has been barred from using the card, and the card has been confiscated.
The Customer has been barred from using the card, and the card has not been confiscated.
Public Extension Points
None.
Special Requirements
None.
This section presents a condensed extract from the glossary that supports the ACME Super ATM use-case model. The definitions are summarized from the full glossary and domain model that support the ACME Super ATM use-case model, focusing just on those elements of the definitions required to understand the two examples presented.
|
Term |
Description |
Additional Information |
|---|---|---|
|
Account |
An obligation on the part of the financial institution to pay the Customer, on demand and adhering to the terms of the account agreement, a defined sum of money. |
Accounts can be either
|
|
ATM ID/ATM Identifier |
Each ATM machine has a unique identification code. This is the machine’s serial number. |
This allows the ATM to be uniquely identified within the ATM network. |
|
ATM Session Identifier |
A unique identifier for the current Customer session—includes the ATM Identifier. |
This is used to identify the ATM and the ATM session in all dialogues with external systems. This allows Bank Systems and others to track the conversations with the ATM and compare the various logs and audits. |
|
Bank Card |
A physical identification device imprinted with magnetic information pertaining to the issuing financial institution (institution interbank number), the Customer (their Customer number with the issuing financial institution), a Personal Information Number (PIN) chosen by the Customer at the time the card was issued, and a card number. | |
|
Bank Card Information |
The standard information held on a bank card. | |
|
Card Number |
The unique 20-character code associated with the card that allows the Bank System to identify the account. | |
|
Communication Retry Number |
The number of times that the system will attempt to contact the Bank System after a failure. |
One of the system’s configurable parameters. |
|
Communication Time-out Period |
The period of time that the system will wait for a response from the Bank System. |
One of the system’s configurable parameters. |
|
Confiscated Cards |
The set of bank cards the system has retained either deliberately or because of errors. | |
|
Customer |
A person who holds accounts at a financial institution that is a member of the ATM interbank network and who possesses a bank card. | |
|
Customer Number |
The bank system’s 20-character, alpha numeric Customer identification number. Unique within the bank. |
ACME Super ATM handles Customer numbers up to 20 characters in length, although most banks only use 16 character numbers. |
|
Customer’s Bank |
The financial institution that issued the bank card and at which the Customer has an account. The Customer’s bank is contacted by way of the Bank System. The financial institution is identified via by institution interbank number. |
Setting which banks are supported is one of the Super ATM’s configuration options. |
|
Event Log |
A permanent record used to record any noteworthy events within the ATM. The log contains at least the following information for each event:
| |
|
Financial Institution |
An issuer of bank cards and main-tainer of accounts. | |
|
Institution Interbank Number |
A standard code number that uniquely identifies a financial institution. Eight-character, alpha numeric string. |
Used to identify the owning bank on a bank card. |
|
Personal Identification Number (PIN) |
An identification number chosen by the Customer used in conjunction with the bank card for security purposes. The PIN can be up to 6 digits in length and must not include any repeated digits. A PIN is used to verify the identity of the Customer by asking the Customer to reenter the PIN; when the Customer enters the same number as the PIN stored on the card, the Customer’s identity is considered authenticated. | |
|
Service Option |
A customer service available from the ATM. Services available from the Super ATM include
|
The current list of services available is configurable and reflects the state of the ATM (i.e., if there is no cash available in the machine, the Cash Withdrawal service will be unavailable). |
|
Service Organization |
The organization that services the ATM, refilling it with cash and keeping it in working order. | |
|
Smallest Denomination Note Held |
The smallest denomination of note the ATM currently contains. | |
|
Standard Withdrawal Amount |
Standard amounts offered for Customers to withdraw. |
One of the system’s configurable parameters. |
|
Transaction Fee |
The amount charged by the owner of the ATM for undertaking the transaction. | |
|
Transaction Log |
A permanent record used to guard against data loss in the event of a subsequent system failure. The log contains the following information for each transaction:
| |
|
Withdrawal Acceptance |
The message sent by the Bank System to accept a request for the withdrawal of funds from an account. | |
|
Withdrawal Limit |
The maximum amount of cash that can be withdrawn in one transaction. |
One of the system’s configurable parameters. |
|
Withdrawal Receipt |
Customer facing record of a withdrawal typically printed on request. It contains
| |
|
Withdrawal Rejection |
The message sent by the Bank System to reject a request for the withdrawal of funds from an account. It indicates why the withdrawal was rejected particularly if it was because of a lack of funds. |
[1] See Chapter 6, The Life Cycle of a Use Case, for definitions of the other states that use case could be in.
[2] This use case is more of an abuse case than a typical use case, but it does represent one of the stakeholders’ indirect goals for the system: that it should be secure.
[3] In the ACME Super ATM use-case model, the Authenticate Customer use case is included in 4 of the other use cases: Withdraw Cash, Deposit Funds, Transfer Funds, and Manage Account. As shown in Chapter 9, it started out as a subflow in the Withdraw Cash use case but was turned into an included use case as the other use cases were written.