Imam Mohammad bin Saud Islamic University Girls Education Center College of Computer and Information Sciences

IS 395 Software Engineering

1432-1433 First Semester

Dr. Mona Alkhattabi

Tutorial (UML basics)

Tutorial Outline: We will cover the following topics: Understanding a Use Case Writing a Use Case Understanding Actor and Use Case Diagrams

Page 1 of 8

1 Use Case

1.1 Scenario Analysis - Creating Use Cases

The first step in System Definition is Scenario Analysis. In Scenario Analysis, we identify all the relevant business scenarios. In the example that we are going to do in this tutorial, we will be looking at a simplified model of an Automatic Teller Machine (ATM). The following is a requirements specification for the system.

Interview with I M Banker, clerk at the Peoples Bank of Victoria

Q: What can customers do with the ATM? Well, there are lots of things a customer can do with the ATM, they can withdraw money, they can deposit money and a customer can check their balance. Q: How do they do these things? Hmmm. They come up to the machine and insert their card in the slot and the screen goes up, then they are asked for their PIN number, which is then checked by the system. If the PIN is valid, then they select the type of transaction they want and if it is a withdrawal or deposit, they then have to say how much money they are going to withdraw or deposit. For withdraw, they check if there is enough money in the account. Then the money is given out, if its a withdrawal and then for all transactions, a receipt is printed. Q: What can go wrong? Lots! They get it wrong all the time and then they come and complain inside and we have to go and show them. They put the wrong PIN number in three times and lose their cards to the machine; they try and withdraw more money than they have. Sometimes, the machine runs out of receipt cards, which it tells them, but they still come in asking for a receipt. Sometimes the ATM dies in mid-transaction and then it spits back out the card. Sometimes they hit the cancel button by mistake and dont know why the transaction stops and the ATM gives them their card back. Q: Does the ATM have anything else done to it? Yes, each morning, I have to go to it, put it in to stand-by mode, remove the old transaction list disk, put a new one in and then refill it with money and receipt cards.

Page 2 of 8

The following problem statement describes how the automated teller machine network operates:

The software to be designed will control an 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, a printer for printing customer receipts, and a key-operated switch to allow an operator/clerk to start or stop the machine. The ATM will communicate with the bank's computer over an appropriate communication link. (The software for the communications with the banks computer is not part of the requirements for this problem.). In addition, the ATMs are to be shared by a consortium of banks, where the cost of the shared system will be apportioned to the banks according to the number of customers with cards. 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 ATM provides 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. 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 in an envelope. The customer will enter the amount of the deposit into the ATM. 3. A customer must be able to make a balance inquiry of any account linked to the card. The ATM will have a key-operated switch that will allow an operator to start and stop the servicing of customers. 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.

Using the interview and the problem statement, write down the possible use cases for the system

Page 3 of 8

Obvious Use Cases

Check Balance Withdraw Money Deposit Money Service ATM

Less Obvious Use Case

Validate User

Possible Use Cases

Issue Cash Issue Receipt but what does the actor do in these use cases? Do Transaction Generalisation of the three basic use cases

1.2 Writing the Use Cases for the ATM System

For each of the use cases selected by your tutor, write the use case using the provided use case template. It can be found online with the lab materials. Get them to write the Withdraw Money use case and the Check Balance use case This demonstrates the commonality of the Validate User use case

An Abstract Withdraw Cash Use Case

Actor Action 1. Customer identifies self

System Response

2. System verifies identity 3. System offers choices 4. Customer chooses withdraw cash 5. Customer chooses amount 6. System dispenses cash 7. Customer takes cash
Page 4 of 8

This use case is as abstract as it gets. We now have a description of the task of withdrawing cash without specifying the technology or method used to do this. We have WHAT HAPPENS but not HOW IT HAPPENS. Deposit Money and Check Balance will have the same initial 3 steps.

1.3 Create a Use Case Diagram for the ATM System Using the use cases that the class agreed upon for the ATM System, create a use case diagram for the ATM System. 1.3.1 A Simple but Correct Solution

Page 5 of 8

Problems: We will have much duplication of text within our expanded use cases e.g Actor Action System Response System Asks for Pin No. Customer enters PIN No. System Validates PIN No. There will be lots of other duplication as well: Entering the Card and check if it is a valid card, i.e not a drivers license or inserted the wrong way. The machine opening Choosing to receive a receipt Printing and dispensing a receipt 1.3.2 A Moderate Solution

Page 6 of 8

This diagram solves the repetition of the Validating the User part of the process, but still will have repetition in other areas. 1.3.3 An advanced solution

Minimal duplication of text in out expanded use cases with this solution

Page 7 of 8

1.3.4 A wrong solution Why this solution is wrong?

Page 8 of 8