Use Cases College of Alameda Copyright © 2007 Patrick McDermott

The Use Case Use Case Diagrams are a powerful tool to specify and discuss user’s roles. They contain Scenarios, which are often used as design or coding specs. Use brainstorming techniques to help come up with Use Cases and Use Case Scenarios to better understand the problem. The Purpose of Use Case Diagrams —How users interact with a system

What’s a Use Case? A use case defines discrete system behavior of value to a particular actor (user role). The best use cases are those written in active voice, in present tense, in terms of user action/system response (“the user does this; the system responds by doing that”), and unambiguously using the terms defined in an accompanying glossary or domain model. A single project may have hundreds of use cases defined. Because the use case defines external system behavior (as observed by the user), it doesn’t make inroads into design. In other words, it defines the “what” of a system (as in, what do we want this system to do?) rather than the “how” (as in, how shall it do it?).

Business Level Use cases are meant to help you understand what a system should do—and often to explain the system to others (like the customer or your boss). If your use case focuses on specific code-level details, it’s not going to be useful to anyone but a programmer. As a general rule, your use cases should use simple, everyday language. If you’re using lots of programming terms, or technical jargon, your use case is probably getting too detailed to be that useful. — H1 st OOA&D, p. 77

We are Driven ?Procedure Driven ?Data Driven ?Object Driven ?Business Rules Driven ?Test-Driven ?Workflow Driven !Sharp & McDermott ?Use Case Driven [OOSE] –Booch, Rosenberg, Deitels, Agile, etc.  Real Goal: -Driven Chauffer ________

A Use Case… Describes What your System Does to accomplish a particular Customer Goal: –What: Use cases are all about the “what” –System: The complete app or project –Does: what the system needs to “do”. –Particular: A single UC focus on a single goal –Customer Goal: “The customer goal is the point of the use case: what do all these steps need to make happen? We’re focusing on the customer, remember? The system has to help that customer accomplish their goal.” — H1 st OOA&D, p. 72.

More Formally… “A use case is a technique for capturing the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific goal.” — H1 st OOA&D, p. 73.

Use Case Benefits  Defines the System Boundary ↨Shows Scope  IDs Actors ☺Meaningful to User  Use to Identify/Cross-check class es  Validate the Requirements document

Discovery Brainstorm Events Actors Document Analysis CRUD your Classes CRUD your Relationships Key Attributes Methods…

Use Case A use case will usually define an individual task that is equal to or is less than a business process. It will usually take place at a single place and time from the user’s point-of-view. It should be logically complete and deliver something of use to the user. It will refer to work done in a process by one actor at one (contiguous) time.

Example In an activity called Take Order, getting the customer’s name is not a good use case, it’s part of one, because an order is not logically complete until we know what it is the customer wants to order. The activity is Take an Order, and includes both identifying the customer and recording the items being ordered.

The Book Rumbaugh, James, Ivar Jacobson & Grady Booch [“The Three Amigos”], The Unified Modeling Language Reference Manual, Second Edition, Upper Saddle River, New Jersey: Addison-Wesley ( ), 2006 (2005).

3 Parts to UC Goodness 1.Clear Value: Every use case must have a clear value to the system. If the use case doesn’t help the customer achieve their goal, then the use case isn’t of much use. 2.Start & Stop: Every use case must have a definite starting and stopping point. Something must begin the process, and then there must be a condition that indicates the process is complete. 3.External Initiator: Every use case is started off by an external initiator, outside of the system. Sometimes that initiator is a person, but it could be anything outside of the system.

Requirements Ripple to UC Check your requirements against your Use Cases A Change to the Requirements implies a change to the UCs Each UC should relate to 1 or more Requirements  Else why is it there? Each Requirement should be addressed 1 or more UCs

A Use Case has Scenarios Use Case Scenario Class Requirements Program Spec Class Diagram