1. Techniques of identifying use cases List all users who will use the system. Start with existing system, and list system functions already included. Talk to all the users, to get them to describe goal of system.

2. Importance of Use Case diagrams To identify functions and how roles interact with them. It gives high level view of the system. Identify internal and external factors. Ex: Email Management system can be an actor for send email use case.

3. Use Case diagram objects Actor Use Case System Boundary Package

4. Actor performs role in the system. Use Cases represent functions System Boundary defines the scope of use case (optional). Package is a group of use cases.

5. USE Case diagram guidelines Give meaningful names to actors Primary actors, should come on left.( optional) Actors model roles not positions. External systems can be actors. Actors don’t interact using associations, but can have generalization. Use cases guidelines.( Next Slide)

6. Symbol should be for actors.

7. Name starts from verb. Name should be descriptive. Highlight in logical order. Ex: Open_acc, Deposit_amount, Withdraw_amount. Place included use case or extending use case to right. Place Extending Use Case below parent use case.

9. E T S UC R D Save Money enter details Cust Open_Acc Acc Details Cust Save Money enter fund details Cust Deposit_fund Deposit details Cust Get Money enter amount Cust Withdraw_fund Update details Cust Print PB Passbook Cust Request_Stmt Update PB Cust Closing Acc enter details Cust Close_ acc Update DB Cust

12. In a Use Case Diagram 1)relation between actor and use cases is uni directional or bi directional 2) The relation between use cases are called as stereotypes. ( include or extend) 3) The relation between actors, if it exists, is called as generalization. 4) Stereotypes are always uni directional. For Use Cases - - - - - -> <- - - - - Between use cases Between Actors Generalization Other way round also

13. Meaning of include and extend Include: The behaviour of included use case is a part of including (base) use case. Note: 1)The Base Use Case is incomplete, without included use case. 2)The included use case is mandatory, not optional. 3) Shown by dotted arrow. Extend: The extending use case, extends the base use case, and adds more functionality to base use case. Note: 1)The extending use case is dependent on base use case. 2)The extending use case is optional, and can be triggered conditionally. 3) Shown by dotted arrow.

14. Event : 1)It occurs at a specific time. 2) End users can define the events. Types of events: External Event: Customer places order. This is w.r.t. external user. Temporal Event: 1)These events depend on time. Generate performance report, during payroll clearance. 2) performance report( TE) has to be automatically generated, when clerk is clearing the payroll clearance, without the clerk telling. State Events: State events, happen, when some events inside the system, triggers the need for processing. Ex: Sell Product event triggers update inventory.

15. Event Decomposition Technique Any event should define EBP ( Elementary Business Process) Ex 1: Maintain Bank is not EBP. Event: Open Bank ( At a particular time). It doesn’t add value, with respect to customer. Ex 2: Deposit Money is EBP. Event: Want Money ( At a particular time). It adds value with respect to customer. Also find Goal of Use Case, and Role of Actors ( Trigger and Response). For 1 Goal is Maintenance of Bank. For 2 Goal is Accumalating money in Bank. Activity, is collection of events, which defines use case. Activity, process’s use Case.

16. To find events, we have 1) System Control events ( Performance Aapprisal) 2) Technology based events ( Payroll Generation )