Embed Size (px)
Citation preview
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.—H1st 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: -DrivenChauffer________
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.”—H1st 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.”—H1st OOA&D, p. 73.
Use Case BenefitsDefines the System Boundary
↨ Shows Scope
IDs Actors☺Meaningful to UserUse to Identify/Cross-check classes Validate the Requirements document
Discovery
BrainstormEventsActorsDocument AnalysisCRUD your ClassesCRUD your RelationshipsKey AttributesMethods…
Use CaseA 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 (0-321-24562-8), 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 UCCheck your requirements against your Use
CasesA Change to the Requirements implies a
change to the UCsEach 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
Use Case
Scenario Class
Requirements
Program Spec
Class Diagram
