Usecase Diagram

  • June 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Usecase Diagram as PDF for free.

More details

  • Words: 1,752
  • Pages: 27
Introduction to the UML Module : Use Cases Diagram

Introduction

What us an Actor • Actors are not part of the System • Actors represent roles a user of the system can play • They can represent a human, a machine, or another system • They can actively interchange information with the system • They can be a giver of information • The can be a passive recipient of information • Actors may be connected to use cases only by association

Actor

Identifying Actors Who uses the system? Who installs the system? Who maintains the system? What other systems use this system? Who provides info to the system? Does anything happen automatically at a preset time?

Organizing Actors

Person

Employee

Librarian

Managerr

Member

Supplier

What Is a Use Case ? A description of a sequence of actions a system performs that yields an observable result. A use case models a dialog between actors and the system A use case is initiated by an actor to invoke a certain functionality in the system Defines a behavior of the system,without showing the internal structure of the system Every use case must have a name that distinguishes it from other use cases. Syntax is similar to other classifiers Use case names start with a verb. For example, Log on, prepare statement Validate user Simple name

Security:: Log on

Place order Path name

Who use the Use Cases? For Clients Customer: approve what the system should do Users: understand what the system should do

For developers Requirement specs: Use-case is a tool to refine software requirements Designers: find design classes Testers: use as basis for test cases Project Manager: manage the project Technical Writers: write user’s guide

Identifying Use Cases Ask yourself: • What functions will the actor want from the system? • Does the system store information? What actors will create, read, update or delete that information? • Does the system need to notify an actor about changes in its internal state? • Are there any external events the system must know? What actor informs the system about those events?

Use Cases and Flow of Events A use case describes what a system does but does not specify how it does it. You can specify the behavior of a use case by describing a flow of events in text clearly The flow of events should include how and when the use case starts and ends You can specify a use cases flow of events in a number of ways, including informal structured text, formal structured text (with pre and post conditions) and pseudocode.

Developing a Step-by-Step Outline for each Use Case Developing a use case sequence of actions is an iterative process. We start by developing an outline or a sketch first. Later you add in the descriptions. The basic flow shows the major steps in accomplishing the goal of the use case. The alternative flows show alternative behavior. They show what may go wrong and optional behavior.

Step-by-Step Outline

1.

2 3 4

Example: Step-by-Step Outline - Enroll for Subjects

Flow of Events Basic flow of events - should be relatively short. It should be very easy to read. Should show the steps needed to achieve the main goals of the use case. Alternative flows - gets most of the other details. These alternative flows can return to the basic flow of events and some can end the execution of the use case. Alternative flow

•Happy day scenario • Successful scenario from start to finish • Basic flow

Questions to ask when you outline the Flow of Events Basic Flow: What event(s) starts the use case? How does the use case end? How does the use case repeat some behavior?

Alternative Flows: Are there optional situations in the use case? What variants might happen? What odd case (unusual things) might happen? What may go wrong? What may not happen? What kind of resources can be blocked? How the user expect to interact with the system in each scenario.

Flow of Events in an ATM System Main Flow 1. use case starts when system asks for the Custom er PIN 2. C ustomer can now enter aPIN via the keyboard. 3. The customer commits the entry by pressing the 'E nte r' button. 4. The system checks the PIN for validity and acknow leges the entry

Customer

Validate User

Exceptional Flow Of Events (Num 1) 1. The customer cancels the transaction at any tim e by pressing the 'Cancel' button. 2. R estart the use case Exceptional Flow of Events (N um 2) 1. The C ustom er ca n clear the PIN anyti me before com miting it and re-enter a new PIN Exceptional Flow of Events (N um 3) 1. If the customer enters an invalid PIN the use case re-starts If this happens 3 times in a row, the system

...

Organizing Use Cases You can use use cases by grouping them in packages in the same manner as in organizing classes. You can also organize use cases by specifying generalization, include and extend relationships among them

Organizing Use Cases (cont.)

The <> Relationship in Use Cases A base use case can explicitly incorporate the behavior of another use case at a location specifies in the base use case. The included use case never stands alone You use an <> relationship to avoid describing the same flow of events several times. The included use case will therefore contain the common behavior of a specific system. <> withdraw money base use case

validate user extended use case

Put all the Common Flows into One Use Case Validate User

1.xxxxxxxx 2,xxxxxxxxxxxxx 3.xxxxxxxxxxxxxxx 4.xxxxxxxxxxxxxxxxxx 5.xxxxxxxxxxxxxxxxx 6. Xxxxxxxxxxxxxxx 7.xxxxxxxxxxxxxxxx 8.xxxxxxxxxxxxxxxxxxx

Deposit Money

1.xxxxxxxx 2,xxxxxxxxxxxxx 3.xxxxxxxxxxxxxxx 4.xxxxxxxxxxxxxxxxxx 5.xxxxxxxxxxxxxxxxx 6. Xxxxxxxxxxxxxxx 7.xxxxxxxxxxxxxxxx 8.xxxxxxxxxxxxxxxxxxx

Withdraw Money

1.xxxxxxxx 2,xxxxxxxxxxxxx 3.xxxxxxxxxxxxxxxx 4.xxxxxxxxxxxxxxxxxx 5.xxxxxxxxxxxxxxxxx 6. Xxxxxxxxxxxxxxx 7.xxxxxxxxxxxxxxxx 8.xxxxxxxxxxxxxxxxxxx 9.xxxxxxxxxxxxxxx

Request Money

1.xxxxxxxx 2,xxxxxxxxxxxxx 3.xxxxxxxxxxxxxxxx 4.xxxxxxxxxxxxxxxxxx 5.xxxxxxxxxxxxxxxxx 6. Xxxxxxxxxxxxxxx 7.xxxxxxxxxxxxxxxx 8.xxxxxxxxxxxxxxxxxxx 9.xxxxxxxxxxxxxxx

Check Statement

1.xxxxxxxx 2,xxxxxxxxxxxxx 3.xxxxxxxxxxxxxxxx 4.xxxxxxxxxxxxxxxxxx 5.xxxxxxxxxxxxxxxxx 6. Xxxxxxxxxxxxxxx 7.xxxxxxxxxxxxxxxx 8.xxxxxxxxxxxxxxxxxxx 9.xxxxxxxxxxxxxxx

Transfer Money

1.xxxxxxxx 2,xxxxxxxxxxxxx 3.xxxxxxxxxxxxxxxx 4.xxxxxxxxxxxxxxxxxx 5.xxxxxxxxxxxxxxxxx 6. Xxxxxxxxxxxxxxx 7.xxxxxxxxxxxxxxxx 8.xxxxxxxxxxxxxxxxxxx 9.xxxxxxxxxxxxxxx

Using <> in an ATM System depos it money <>

<>

withd raw m o ney

Check pass word <>

Custom er

validate user reques t s tatem ent

<>

<> check balance

trans fer mon ey

Retinal Scan

The <<extend>> Relationship in Use Cases An <<extend>> relationship means that the base use case implicitly incorporates the behavior of another use case (called the extending use case) at a location (called an extension point) declared in the base use case. You may list the extension points of the base use case in an extra compartment. You use an <<extend>> relationship to separate optional behavior from mandatory behavior You may also use an <<extend>> relationship to model a separate subflow that is executed under given conditions. A use case may have many extension points, which the extending use case may extend. You indicate which ones on the line between the use cases. Buy Products

<<

>>

! "#

Browse Web Site extension point click buy

<<extends>> Relationship –an example Extending Use Case Frequent Customer Discount -----------------------------------------------------------------------if customer in Special Customer List then Special Customer Extension. 1.The system will get the customer discount 2. The system will display the discount on the order 3. The system will calculate the discount amount 4. The system will subtract the discount from the total

Extens ion Points ____________________________ Sale Item, before step 5 Special Customer, before step 6

<<extend>> Special Customer Place Order

Frequent Customer Discount Extending Use Case Seasonal Sale Price _____________________________________________________ if product in Seasonal Sale list then At Sale Item extension 1. The system will 2. The system will 3. The system will 4. The system will total

<<extend>> Sale Item

get the sale discount for the product display the discount on the order calculate the discount amount subtract the discount amount from the order Seasonal Sale Price

Place Order Use Case _________________________________________________ 1. The use case starts when customer selects 'Place Order' 2. The customers enters name and address 3. The customer enters product codes for the order 4. The system will display a product description and a price for each product 5. The system will maintain a total of items ordered as they are entered. 6. The customer will enter credit card information 7. The customet will select 'Submit' 8. The system will verify the info, save the order as pending, and send payment info to the accounting system 9. When payment is confirmed, the order is marked as confirmed, an order ID is returned to the customer and the use case ends

EP EP

Place Order Use Case _________________________________________________ 1. The use case starts when customer selects 'Place Order' 2. The customers enters name and address 3. The customer enters product codes for the order 4. The system will display a product description and a price for each product 5. The system will maintain a total of items ordered as they are entered. 6. The customer will enter credit card information 7. The customet will select 'Submit' 8. The system will verify the info, save the order as pending, and send payment info to the accounting system 9. When payment is confirmed, the order is marked as confirmed, an order ID is returned to the customer and the use case ends

Extending Use Case Seasonal Sale Price _____________________________________________________ if product in Seasonal Sale list then At Sale Item extension 1. The system 2. The system 3. The system 4. The system total

will will will will

get the sale discount for the product display the discount on the order calculate the discount amount subtract the discount amount from the order

Ext ending Use Case Frequent Cus tomer Discount -----------------------------------------------------------------------if cust omer in Special Customer List then Special Cust omer Extension. 1.The syst em will get t he cus tomer discount 2. The sy stem will display the discount on the order 3. The sy stem will c alculat e t he discount amount 4. The sy stem will s ubtract the discount from t he t otal

Which Relationship Do I Use? Apply the following rules: Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition Use generalization when you are describing a variation on normal behavior and you wish to describe it casually Use extend when you are describing a variation on normal behavior and you wish to use the more controlled form, declaring you extension points in your base use case.

End of Session

Related Documents

Usecase Diagram
June 2020 3
Usecase
November 2019 10
Usecase
November 2019 14
Usecase Template
December 2019 24
Opis Usecase
November 2019 24
Diagram
June 2020 33