4/11/13

Use Case Documenta.on

Documents the detailed behavior and assump.ons about a par.cular Use Case. Through a detailed ow of events.
Descrip.on of the normal and alternate ow of events that occur when the use case is ini.ated.

21

Use Case Documenta.on

1. Use Case Name 2. Short Descrip5on of the Use Case 3. Precondi5ons Describe the state of the system before the use case occurs by lis.ng any condi.ons that must be true before an actor can ini.ate this use case. Eg.: To be able to check out a book, the book must be available and the client must not have any overdue nes. 4. Normal Flow/Scenario: present the primary or normal ow of interac.on events that accomplish the purpose of the use case. 5. Alterna5ve Flow/Scenarios: present possible alterna.ve ows of interac.on events. This subsec.on can be used to describe error handling scenarios and/or alterna.ve sub-use cases. 6. Post condi5ons: Specify the system states that result aFer the use case has completed, AND the event(s) that mark the end of the use case. 7. Other Requirements: resource constraints, other qualify factors (e.g. reliability).
22

4/11/13

2 ways of wri.ng use case documenta.on for withdraw, deposit and approval process

Approach 1: Write use case documenta5on for withdraw & deposit only
Use-Case: UC-002: Withdraw Cash Brief Descrip5on This use case describes how the Bank Client uses the ATM to withdraw money from his bank account. Actors: Bank Client Precondi5ons: There is an ac.ve network connec.on to the Bank. The ATM has cash available

4/11/13

Normal Flow: 1. The use case begins when Bank Client inserts their Bank Card. 2. The ATM reads the code from the magne.c strip of the Bank Card and checks with the Bank to see if it is an acceptable Bank Card. The Bank conrms the card is valid. If the card is invalid, Alterna.ve ow 1 is performed. If there is no response from the Bank within 3 seconds, Alterna.ve ow 4 is performed. 3. The ATM asks for the Bank Client PIN code (4 digits). 4. The Bank Client enters a PIN code. If there is no response from the Bank Client within 15 seconds, Alterna.ve ow 5 is performed. 5. The ATM validates the PIN code with the Bank. The Bank conrms the PIN is valid. If the PIN code is invalid for the rst and second .me, Alterna.ve ow 2 is performed. If the PIN code is invalid for the third .me, Alterna.ve ow 3 is performed. If there is no response from the Bank within 3 seconds, Alterna.ve ow 4 is performed. : : :

Alterna.ve Flow: 1. Not a valid card The ATM shall display a Sorry not a valid card message and return the card. The use case ends with an indica.on of the failure. 2. Wrong PIN code (1st. and 2nd .me) The ATM shall display a Sorry invalid PIN code message. The use case resume at Normal ow 3. 3. Wrong PIN code (3rd. .me) The ATM shall display a Sorry invalid PIN code Please contact your branch message. The card is kept by the ATM and a receipt is printed telling how and where to get a new card. The use case ends with an indica.on of the failure.

4/11/13

Post-Condi.ons
Successful Comple.on
The user has received their cash and the internal logs have been updated.

Failure Condi.on
The logs have been updated accordingly.

Special Requirements Use Case Extensions

Approach 2: Write use case documenta5on for withdraw, deposit & validate user
Use-Case: UC-001: Validate User Brief Descrip5on This use case describes general behaviour for the ATM to validate the user. It includes all steps that are the same no ma]er what kind of transac.on the Bank Client does. Actors: Bank Client Precondi5ons: There is an ac.ve network connec.on to the Bank.

4/11/13

Normal Flow: The use case begins when Bank Client inserts their Bank Card. The ATM reads the code from the magne.c strip of the Bank Card and checks with the Bank to see if it is an acceptable Bank Card. The Bank conrms the card is valid. If the card is invalid, Alterna.ve ow 1 is performed. If there is no response from the Bank within 3 seconds, Alterna.ve ow 4 is performed. The ATM asks for the Bank Client PIN code (4 digits). The Bank Client enters a PIN code. If there is no response from the Bank Client within 15 seconds, Alterna.ve ow 5 is performed. The ATM validates the PIN code with the Bank. The Bank conrms the PIN is valid. If the PIN code is invalid for the rst and second .me, Alterna.ve ow 1.2 is performed. If the PIN code is invalid for the third .me, Alterna.ve ow 1.3 is performed. If there is no response from the Bank within 3 seconds, Alterna.ve ow 4 is performed. The ATM displays the dierent alterna.ves that are available on this unit. : :

Alterna5ve Flow: 1. Not a valid card The ATM shall display a Sorry not a valid card message and return the card. The use case ends with an indica.on of the failure. 2. Wrong PIN code (1st. and 2nd .me) The ATM shall display a Sorry invalid PIN code message. The use case resume at Normal ow 3. 3. Wrong PIN code (3rd. .me) The ATM shall display a Sorry invalid PIN code Please contact your branch message. The card is kept by the ATM and a receipt is printed telling how and where to get a new card. The use case ends with an indica.on of the failure. : :

4/11/13

Post-Condi5ons Successful Comple.on The user is validated and may con.nue with the specic transac.on Failure Condi.on The ATM shall log the event including the reason for the failure. Special Requirements Related Use Cases
UC-002: Withdraw Cash UC-003: Deposit Cash This part is to show which use case will use this use case

Use-Case: UC-002: Withdraw Cash Brief Descrip5on This use case describes how the Bank Client uses the ATM to withdraw money from his bank account. This statement just Actors: Bank Client call all the process Precondi5ons: inside the Validate There is an ac.ve network connec.on to the Bank. User. So, we dont The ATM has cash available need to respecify the process. Normal Flow: The use case begins when Bank Client inserts their Bank Card. Use Case: UC-001: Validate User is performed. If the use case does not complete successfully, AlternaCve ow 1 is performed. The ATM displays the dierent alterna.ves that are available on this unit. In this case, the Bank Client select Withdraw Cash. : :

4/11/13

Alterna5ve Flow: 1. Invalid User The use case ends with a failure condi.on. Post-Condi5ons Successful Comple.on The user has received their cash and the internal logs have been updated. Failure Condi.on The logs have been updated accordingly. Special Requirements Use Case Extensions This part is to show the UC-001: Validate User <<includes>> rela.on between the use cases.

Sequence Diagram
Represents the sequence and interac.ons of a given use case or scenario. Steps:
1. Iden.fying classes in a scenario. 2. Iden.fying interac.ons between class 3. Iden.fying stereotype of the class.

34

4/11/13

Normal Flow: a. The use case begins when Bank Client inserts their Bank Card. b. The ATM reads the code from the magne.c strip of the Bank Card and checks with the Bank to see if it is an acceptable Bank Card. The Bank conrms the card is valid. If the card is invalid, Alterna.ve ow 1 is performed. If there is no response from the Bank within 3 seconds, Alterna.ve ow 4 is performed. c. The ATM asks for the Bank Client PIN code (4 digits). d. The Bank Client enters a PIN code. If there is no response from the Bank Client within 15 seconds, Alterna.ve ow 5 is performed. e. The ATM validates the PIN code with the Bank. The Bank conrms the PIN is valid. If the PIN code is invalid for the rst and second .me, Alterna.ve ow 2 is performed. If the PIN code is invalid for the third .me, Alterna.ve ow 3 is performed. If there is no response from the Bank within 3 seconds, Alterna.ve ow 4 is performed. f. The ATM displays the dierent alterna.ves that are available on this unit. In this case, the Bank Client select Withdraw Cash. g. The ATM prompts for an account. h. The Bank Client selects an account.

i. The ATM prompts for an amount. j. The Bank Client enters an amount. k. Money is dispensed. l. The Bank Card is returned. m. The receipt is printed. Alterna5ve Flow: 1. Not a valid card a. The ATM shall display a Sorry not a valid card message and return the card. b. The use case ends with an indica.on of the failure. 2. Wrong PIN code (1st. and 2nd .me) a. The ATM shall display a Sorry invalid PIN code message. b. The use case resume at Normal ow 3. 3. Wrong PIN code (3rd. .me) a. The ATM shall display a Sorry invalid PIN code Please contact your branch message. b. The card is kept by the ATM and a receipt is printed telling how and where to get a new card. c. The use case ends with an indica.on of the failure.

4/11/13

Iden.fying classes in a scenario

List all Noun Phrases Eliminate irrelevant classes Reviewing the redundant classes and building a common vocabulary. Reviewing the possible a]ributes. Reviewing the class purpose.

37

Ini.al Candidate Class

Bank Client ATM Card 4 digits PIN code System Account Transac.on Amount ATM Card Message A]empts Code Client

38

4/11/13

Remove irrelevant classes

39

Review redundant class and building a common vocabulary

If dierent words are being used to describe the same idea, we must select the one that is the most meaningful in the context of the system and eliminate the others.
Client, Bank Client = Bank Client (the term chosen)

40

10

4/11/13

Review redundant class and building a common vocabulary (cont.)

41

Review possible a]ributes

The next review focuses on iden.fying the noun phrases that are a]ributes, not classes. The noun phrases used only as values should be restated as a]ributes.
Amount: A value, not a class.

42

11

4/11/13

Review possible a]ributes (cont.)

43

Reviewing the class purpose

Each class must have a purpose. Every class should be clearly dened and necessary in the context of achieving the systems goal. If you cannot formulate a statement of purpose for a class, simply eliminate it.
ATM: provides an interface to the ViaNet bank. BankClient: A client is an individual that has a current account or savings account.
44

12

4/11/13

Reviewing the class purpose (cont.)

45

3 types of messages nota.on

Synchronous: If a caller sends a synchronous message, it must wait un.l the message is done before it proceeds with its business. Asynchronous: (EA) / If a caller sends an asynchronous message, it can con.nue processing and doesnt have to wait for a response. Usually used in mul.threaded applica.ons and in message-oriented middleware. Return message:
46

13

4/11/13

The sequence diagram

47

Iden.fying classes types

UML support 3 types of class:
Boundary Class: <<boundary>>
used to model interac.on between the system and its actors.

En.ty Class: <<en.ty>>

used to model informa.on that is long-lived and oFen persistent.

Control Class: <<control>>

used to represent coordina.on, sequencing, transac.ons, and control of other objects. And it is oFen used to encapsulate control related to a specic use case.

48

14

4/11/13

A revise sequence diagram

49

15