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