Requirements Statement for Example ATM System

The software to be designed will control a simulated automated teller machine (ATM) having a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. The ATM will communicate with the bank's computer over an appropriate communication link. (The software on the latter is not part of the requirements for this problem.) The ATM will service one customer at a time. A customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation as part of each transaction. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that he/she desires no further transactions, at which point it will be returned - except as noted below. The ATM must be able to provide the following services to the customer: 1. A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed. 2. A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope. 3. A customer must be able to make a transfer of money between any two accounts linked to the card. 4. A customer must be able to make a balance inquiry of any account linked to the card. A customer must be able to abort a transaction in progress by pressing the Cancel key instead of responding to a request from the machine. The ATM will communicate each transaction to the bank and obtain verification that it was allowed by the bank. Ordinarily, a transaction will be considered complete by the bank once it has been approved. In the case of a deposit, a second message will be sent to the bank indicating that the customer has deposited the envelope. (If the customer fails to deposit the envelope within the timeout period, or presses cancel instead, no second message will be sent to the bank and the deposit will not be credited to the customer.) If the bank determines that the customer's PIN is invalid, the customer will be required to reenter the PIN before a transaction can proceed. If the customer is unable to successfully enter the
1

time. machine location. After turning the switch to the "on" position. amount. The ATM will also maintain an internal log of transactions to facilitate resolving ambiguities arising from a hardware failure in the middle of a transaction. so that the operator may remove deposit envelopes and reload the machine with cash. the operator will be required to verify and enter the total cash on hand. Entries will be made in the log when the ATM is started up and shut down. account(s). The machine can only be turned off when it is not servicing a customer. but for security will never contain a PIN. type of transaction. When the switch is moved to the "off" position. and for the receiving of an envelope. the machine will shut down. the card will be permanently retained by the machine. Log entries may contain card numbers and dollar amounts. If a transaction fails for any reason other than an invalid PIN. and ending and available balance(s) of the affected account ("to" account for transfers). for the dispensing of cash. The ATM will have a key-operated switch that will allow an operator to start and stop the servicing of customers.PIN after three tries. showing the date. 2 . and will then ask the customer whether he/she wants to do another transaction. and the customer will have to contact the bank to get it back. the ATM will display an explanation of the problem. for each message sent to the Bank (along with the response back. etc. if one is expected). blank receipts. The ATM will provide the customer with a printed receipt for each successful transaction.

Use Cases for Example ATM System 3 .

the customer is asked whether he/she would like to perform another. transfer. The customer may abort the session by pressing the Cancel key when entering a PIN or choosing a transaction type. choosing from a menu of possible types of transaction in each case. account(s) involved. The flows of events for the individual types of transaction (withdrawal. the card is ejected. (If the reader cannot read the card due to improper insertion or a damaged stripe. the session is also aborted. Then the servicing of customers can begin. When the customer is through performing transactions.Flows of Events for Individual Use Cases of ATM System System Startup Use Case The system is started up when the operator turns the operator switch to the "on" position. and a connection to the bank will be established. an error screen is displayed. the card is ejected from the machine and the session ends. Transaction Use Case Note: Transaction is an abstract generalization. with the card being retained in the machine. and then turns the operator switch to the "off" position. The transaction will then be sent to the bank. Session Use Case A session is started when a customer inserts an ATM card into the card reader slot of the machine. If a transaction is aborted due to too many invalid PIN entries. After each transaction. Then the operator is free to remove deposited envelopes. along with information from the customer's card and the PIN the customer entered. The connection to the bank will be shut down. System Shutdown Use Case The system is shut down when the operator makes sure that no customer is using the machine. Each specific concrete type of transaction implements certain operations in the appropriate way. The ATM pulls the card into the machine and reads it. inquiry) give the features that are specific to that type of transaction. A transaction use case is started within a session when the customer chooses a transaction type from a menu of options. The flow of events given here describes the behavior common to all types of transaction. replenish cash and paper. amount). etc. The operator will be asked to enter the amount of money currently in the cash dispenser. The customer will be asked to furnish appropriate details (e. and the session is aborted.) The customer is asked to enter his/her PIN. and is then allowed to perform one or more transactions. 4 .g. deposit.

the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. (The dispensing of cash is also recorded in the ATM's log.) If the transaction is approved by the bank. and to choose a dollar amount from a menu of possible amounts.g. a screen will be displayed informing the customer of the reason for the failure of the transaction. or fails for any reason other than repeated entries of an invalid PIN. and the customer will not be offered the option of doing another. If the bank reports that the customer's PIN is invalid. The customer may cancel a transaction by pressing the Cancel key as described for each individual type of transaction below.g.contingent on manual verification of the deposit envelope contents by an operator later. If the transaction is approved. to confirm that the bank can credit the customer's account . checking) from a menu of possible accounts. the customer is informed and asked to enter a different amount.g. any steps needed to complete the transaction (e. and to type in a dollar amount on the keyboard. the appropriate amount of cash is dispensed by the machine before it issues a receipt. (The receipt of an envelope is also recorded in the ATM's log. checking) from a menu of possible accounts. the transaction will be aborted. If a transaction is cancelled by the customer. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. and then a receipt will be printed.) A withdrawal transaction can be cancelled by the customer pressing the Cancel key any time prior to choosing the dollar amount. Once the envelope has been received.If the bank approves the transaction. and then the customer will be offered the opportunity to do another. a second message is sent to the bank. dispensing cash or accepting an envelope) will be performed. 5 . (If not. If the customer's card is retained due to too many invalid PINs. Then the customer will be asked whether he/she wishes to do another transaction. The transaction is automatically cancelled if the customer fails to insert the envelope containing the deposit within a reasonable period of time after being asked to do so. the Invalid PIN extension will be performed and then an attempt will be made to continue the transaction.) A deposit transaction can be cancelled by the customer pressing the Cancel key any time prior to inserting the envelope containing the deposit. Withdrawal Transaction Use Case A withdrawal transaction asks the customer to choose a type of account to withdraw from (e. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. All messages to the bank and responses back are recorded in the ATM's log. Deposit Transaction Use Case A deposit transaction asks the customer to choose a type of account to deposit to (e.

Inquiry Transaction Use Case An inquiry transaction asks the customer to choose a type of account to inquire about from a menu of possible accounts. Once the PIN is successfully re-entered. to choose a different account to transfer to. otherwise the process of re-entering the PIN is repeated. No further action is required once the transaction is approved by the bank before printing the receipt. A transfer transaction can be cancelled by the customer pressing the Cancel key any time prior to entering a dollar amount. The customer is required to re-enter the PIN and the original request is sent to the bank again. No further action is required once the transaction is approved by the bank before printing the receipt. If a certain use case uses several others. checking) from a menu of possible accounts. the card is permanently retained. the original transaction is cancelled.) This symbol can be referred to as an aggregation operator. If the customer fails three times to enter the correct PIN. the original use case is continued. "at least once" is the only relationship guaranteed by this symbol.Transfer Transaction Use Case A transfer transaction asks the customer to choose a type of account to transfer from (e. and the entire customer session is aborted. or disapproves it for some other reason. because it indicates that a given use case is an aggregate (made up of parts) whose components are the use cases that it uses. and to type in a dollar amount on the keyboard. When do I use the uses arrow? The uses arrow (or uses edge as it would be called in traditional graph thoery) is drawn from a use case X to another use case Y to indicate that the process of doing X always involves doing Y at least once (although it may involve doing it many times. it is used for both the current transaction and all subsequent transactions in the session. If the bank now approves the transaction. that means that all of the component use cases must be completed in the process of completing the 6 . An inquiry transaction can be cancelled by the customer pressing the Cancel key any time prior to choosing the account to inquire about. Invalid PIN Extension An invalid PIN extension is started from within a transaction when the bank reports that the customer's transaction is disapproved due to an invalid PIN. If the customer presses Cancel instead of re-entering a PIN. a screen is displayed informing the customer of this and suggesting he/she contact the bank.g.

First. There is a uses edge from "Check in Passenger" to "Weigh Luggage" and from "Check in Passenger" to "Assign Seat". Luggage must be Weighed and a Seat must be Assigned. representing an airline reservation system. Similarly. and then you would add new use cases that make up the top-level ones. Example: Suppose you wanted to add detail to the diagram shown below. mnemonic way to think about the uses arrow is that it it can be read X uses Y means that "X has a Y" as part of it's behavior. the available space must be checked and the passenger's information must be recorded. A brief.aggregate use case. this indicates that in order to Check in a Passenger. 7 . although there is no specification in UCDs of the order in which these are completed. the diagram indicates that in order to add a reservation to the system. You could imagine breaking these use cases down further to show more detail. you would create a separate diagram for the top-level services.

representing an airline reservation system.When do I use the extends arrow? The extends arrow (or extends edge) is drawn from a use case X to a use case Y to indicate that the process X is a special case behavior of the same type as the more general process Y. You would use this in situations where your system has a number of use cases (processes) that all have some subtasks in common. Example: Suppose you wanted to add detail to the diagram shown below. what you would like to show is that not all of the seats aboard the airplane are exactly alike (some window and 8 . but each one has something different about it that makes it impossible for you to just lump them all together into the same use case. Specifically.

Fortunately. the process of assigning a window seat involves checking for the availability of window seats. But even though these processes are different. UML lets us have both: we write that assigning these two types of seats are different processes. Therefore. whereas the process of assigning an aisle seat involves checking for the availability of aisle seats. so it doesn't make sense to ignore their similarities. they cannot just be given their preference right away. but they are similar in that both processes extend a common. because the seat they want might not be available. and sometimes passengers will express a preference for one of these types of seats but not the other. they are quite similar in a number of other ways. But of course.some aisle seats).) 9 . more general process (assigning seats.

some number of times. but this doesn't make sense: This diagram says that in order to assign a seat you must assign both a window seat AND an aisle seat to the passenger. Never fear. task "Y" will be completed at least once. Using the extends relationship (as shown in the following diagram). but "X" is a special. in some order.What is the difference between uses and extends? Probably the best way to think about these diagram elements is as follows: . that is. you must "Weigh luggage" and "Assign a seat". but only one need be completed in the process of assigning the passenger a seat. more specific case of doing "Y". this situation is correctly handled by the extends relationship. . is that all UCs used by a use case MUST BE DONE before that use case be considered to be complete. you might be tempted to draw a diagram using the uses edge like the one below. 10 . That is."X extends Y" indicates that "X" is a task of the same type as "Y". Example: indicates that in order to successfully "Check-in". in the process of completing task "X". though. Once you realize that there are several types of seat assignment. doing X is a lot like doing Y. however. The key."X uses Y" indicates that the task "X" has a subtask "Y". we can express that there are two ways to assign a seat: assigning a window seat and assigning an aisle seat. but X has a few extra processes to it that go above and beyond the things that must be done in order to complete Y.

11 .

Sign up to vote on this title
UsefulNot useful