1. Use Case Modeling CIS 4800 Kannan Mohan Department of CIS Zicklin School of Business, Baruch College Copyright © 2009 John Wiley & Sons, Inc. Copyright © 2005 Pearson Education Copyright © 2009 Kannan Mohan

2. Learning Objectives What is a use case diagram? What is its purpose? How do we create use case diagrams?

3. Use Case Diagram Example

5. Use Case Modeling - Overview A form of requirements engineering Lets us identify the system boundary, who or what uses the system, and what functions the system should offer Helps us identify and define all processes that our system must support

6. Use Case Modeling Find the system/automation boundary Find actors Find and specify use cases Describe scenarios Iterate until elements are stable

7. Elements in a Use Case Model System boundary/subject – the edge of the system – what part of the system is going to be automated? Actors – who or what uses the system? Use Cases – what do the actors do with the system? Relationships - between actors and use cases

8. Actors A role that someone or something (an external entity) in the environment plays in relation to our system Everything that interacts with the system Note that someone/something can play different roles simultaneously or over time Example – Customer and Administrator (John Doe might play both these roles)

9. Actors Could be a person, another software application, or hardware device – E.g.: Customer, Supply chain management system, printer Same actor can be involved in several use cases Actors are external to the system Do not confuse the role that someone plays with the person itself

10. Actors Who / which – Uses the main functionality of the system (primary actors)? – Needs system support for daily tasks? – Maintains, administers, operates system (secondary)? – Has interest in the results of the system? – Other systems interact with ours?

11. Actors Do things happen in your system at specific points in time that may not be triggered by any actor? Time as an actor Example? – Automatic system backup – Automatic triggering of emails to customers on some occasions

12. Use Cases A specification of sequences of actions that a system performs Yields an observable result of value to a particular actor Provides a functional description of the system and its processes A “case of use” of the system by a specific actor

13. Use Cases Not a class or object, but a process that satisfies some user need Always initiated by an actor Provides value to an actor Written from the point of view of the actors Describe basic functions of the system – What the user can do – How the system responds

14. Finding Use Cases Start with the list of actors that interact with the system. – What function does the actor require from the system? – What does the actor need to do? – Does the actor need to read, create, destroy, modify, or store some kind of information in the system? – Does the system interact with any external system? – Does the system generate any reports?

15. Describing Use Cases Use cases connected to actors through associations Named according to what they performs – E.g.: Purchase insurance policy, Update account Usually starts with a verb

16. Scenario An instance of a use case – E.g.: “Customer purchases insurance” is instantiated as: – “John Doe contacts the system through the web and purchases insurance for his new car”

17. Use Case Specification Use case: Place Order ID: 1 Brief Description: This use case describes the process to follow when a customer places a new order. Primary actors: Customer Secondary actors: None Pre-conditions: The customer must have an account with us. Main flow: Actor actionSystem response 1. Customer searches for item. 2. System provides a list of items that matches the customers search keywords. 3. Customer selects an item. 4. System provides more information about the selected item. 5. Customer chooses to add item to cart.6. System adds item to cart. 7. Customer chooses to proceed to checkout.8. System asks for payment and shipping details. 9. Customer provides details and confirms order.10. System processes order. Post-conditions: Order must be processed and confirmation provided to customer. Alternate flows: Item not available Customer account ineligible for placing new orders

18. Branching: Alternative flows Alternative flows capture errors, branches, and interrupts Alternative flows usually do not return to the main flow Potentially very many alternative flows – Pick the most important ones – If there are groups of similar alternative flows - document one member of the group as an exemplar main flow alternative flows Use case

19. Referencing Alternative Flows List alternative flows at the end of the use case Examine each step in the main flow and look for: – Alternatives – Exceptions – Interrupts

20. An Alternative Flow Example May be triggered – instead of the main flow - started by an actor – after a particular step in the main flow – at any time during the main flow - at any time Alternative flow: Alternative flow: CreateNewCustomerAccount:InvalidEmailAddress Preconditions: 1. The Customer has entered an invalid email address Primary actors: Customer Postconditions: None. The alternative flow begins after step 2.2. of the main flow. The system informs the Customer that he or she entered an invalid email address. 1. 2. ID: 5.1 Brief description: The system informs the Customer that they have entered an invalid email address. Secondary actors: None.

21. Actor Generalization The Customer and the Sales Agent actors are very similar Similar (almost) interactions Simplifying the diagram Sales system ListProducts OrderProducts MakePayment CalculateCommission CustomerSalesAgent

22. Actor Generalization Inheritance Substitutability Parent actor – abstract? Sales system ListProducts OrderProducts MakePayment CalculateCommission PurchaserSalesAgentCustomer ancestor or parent descendents or children generalisation abstract actor

23. Use Case Generalization The ancestor use case must be a more general case of one or more descendant use cases Child use cases are more specific forms of their parent They can inherit, add and override features of their parent Sales system FindProduct FindBookFindCD Customer Use case generalization semantics Use case elementInheritAddOverride RelationshipYes No Extension pointYes No PreconditionYes PostconditionYes Step in main flowYes Alternative flowYes

24. Example with «includes»

25. When use cases share common behavior… The base use case executes until the point of inclusion: include (InclusionUseCase) – Control passes to the inclusion use case which executes – When the inclusion use case is finished, control passes back to the base use case which finishes execution Base use cases are not complete without the included use cases Inclusion use cases may be complete use cases, or they may just specify a fragment of behaviour for inclusion elsewhere «include»

26. Example with «include» Use case: CreateNewOrder Primary actors: Customer and Order Clerk Preconditions: Postconditions: 1. A new order is created. Main flow: include( ValidateCustomerAccount ). Include( LookupItemAvailability ). The system displays item and order details. … 1. 2. 3. ID: 1 Brief description: Customer/Order clerk places new order. Alternative flows: None. Use case: ValidateCustomerAccount Primary actors: Customer and Order Clerk Preconditions: Postconditions: 1. Account has been verified. Main flow: The system asks for login information. The customer/order clerk enters authentication information. The system verifies account 1. 2. 3. ID: 4 Brief description: The customer/order clerk logs in. Alternative flows: None. Seconday actors: None Seconday actors: None

27. «extend» Adding new behaviour into the base use case by inserting behavior from one or more extension use cases The base use case specifies one or more extension points in its flow of events The base use case does not know about the extensions

28. Base Use Case Extension points are not numbered, as they are not part of the flow Use case: ReturnBook Secondary actors: None. Preconditions: 1. The Librarian is logged on to the system. Postconditions: 1. The book has been returned. Main flow: The Librarian enters the borrower's ID number. The system displays the borrower's details including the list of borrowed books. The Librarian finds the book to be returned in the list of books. The Librarian returns the book. … 1. 2. 3. 4. ID: 9 Brief description: The Librarian returns a borrowed book. Alternative flows: None. ReturnBook extension points overdueBook IssueFine «extend» extension point: overdueBook extension point base use case extension use case extension point: overdueBook extension point name Primary actors: Librarian

29. Extension Use Case Extension use cases have one or more insertion segments which are behaviour fragments that will be inserted at the specified extension points in the base use case Extension Use case: IssueFine Primary actors: Librarian Segment 1 preconditions: 1. The returned book is overdue. Segment 1 postconditions: 1. The fine has been recorded in the system. 2. The system has printed out the fine. Segment 1 flow: The Librarian enters details of the fine into the system. The system prints out the fine. 1. 2. ID: 10 Brief description: Segment 1: The Librarian records and prints out a fine. ReturnBook extension points overdueBook IssueFine «extend» extension point: overdueBook the single insertion segment in IssueFine is inserted at the overdueBook insertion point in the ReturnBook use case Secondary actors: None.

30. When to use advanced features? When it simplifies your use case model Use sparingly Remember the purpose – communication with stakeholders – Stakeholders may not understand – Inheritance Extension

31. Writing Use Cases Short and simple Focus on what, not how – Customer presses the OK button vs. – Customer accepts the order Avoid functional decomposition – Often used in traditional/structured approach

32. Avoid Functional Decomposition

33. When to Use ‘Use Case Analysis’ A good choice when the system: – is dominated by functional requirements – has many types of user to which it delivers different functionality – has many interfaces A poor choice when the system: – is dominated by non-functional requirements – has few users – has few interfaces

34. Requirements tracing Relating requirements and use cases Many-to-many relationship – One use case covers many individual functional requirements – One functional requirement may be realised by many use cases CASE support for requirements tracing: – UML tagged values - assign numbered requirements to use cases – Capture use case names in our Requirements Database Requirements Traceability matrix

35. Summary What are actors and use cases? What is the system boundary? How do you determine the above for a given system? What are use case diagrams comprised of? What are the various parts of use case specifications? What is requirements tracing?

36. Summary What is actor generalization? What is use case generalization? What are different types of relationships between use cases? – Explain > and > relationships. What are the general dos and don’ts in writing use cases?