Download
1 / 42
420 likes | 541 Views
An Introduction To Use Cases. Presented by Leslie Munday. Agenda/Contents. What Is A Use Case Use Case Example A Brief Use Case History Types Of Use Case Business Use Case Modeling Advanced Concepts References. Intended Audience.
E N D
An Introduction To Use Cases Presented by Leslie Munday
Agenda/Contents • What Is A Use Case • Use Case Example • A Brief Use Case History • Types Of Use Case • Business Use Case Modeling • Advanced Concepts • References
Intended Audience This presentation is meant as an introduction to developers who wish to understand use cases. At the end of this presentation you should be able to: • Understand the purpose of a use case; • Recognize the basic use case components; • Create business use case activity diagrams.
What Is A Use Case? • Technically, a use casedescribes a sequence of actions, performed by a system (or persons), that yields a result of value to an actor. – Rational Software.
What Does This Mean? A use case tells a story: • It has an introduction (foreword) – Overview of the use case. • It has a beginning (once upon a time..) - ‘the use case begins when ..’ • It has chapters – Steps in the story that are explained to the reader. • It has an ending (.. and they all lived happily ever after) - ‘.. the use case ends.’ • It has alternate endings (sequel) – Alternative flows. • It has a main character – Primary actor. • It has a supporting cast – Secondary actors.
Library, Borrow Book Story Consider a patron wishes to borrow a book from the library: • The patron hands the book and membership card to the librarian. • The librarian requests the library worker locate the customer details for the patron from the library records. • The library worker returns customer details. • The librarian examines the customer details to determine if the patron can borrow books, and if so adds the book selection to the patron details along with its return date. • The librarian enters the return date into the book and hands the book with its return date to the patron. • The librarian hands the updated customer details to the library worker to add to the library records. • The story ends.
Library Story Alternative Flow Suppose that the patron has exceeded their limit of the number of books they can borrow: • When the library worker returns with the customer details the librarian notes that the patron has already reached their limit of books they can borrow. • The librarian requests that the patron returns one of the books they currently have on loan before they may borrow another. • The librarian returns the customer details to the library worker. • The story ends.
Parts Of The Use Case • Name – Uniquely identifies the use case. • Description – An overview of the purpose of the use case. • Primary Actor – The person or organization that initiates and gains the benefit from the use case. • Secondary Actor – People or systems that support the person performing the work. • Worker – The person, organization or system responsible for performing the work in order to satisfy the primary actor. • Precondition – The things that must have occurred before the story begins. • Basic Flow – The expected steps in the use case. • Postcondition – The state of the world after the use case has completed. • Alternate Flow – Steps that are performed as a result of an unexpected event occurring. • Alternate Postcondition – A state that the world may find itself in, as a result of unexpected behavior occurring.
Map The Example To A Use Case • The Primary Actor – • A Secondary Actor – • A Worker – • A Precondition – • A Postcondition – • A Step In The Basic Flow – • An Event That Causes An Alternate Flow – • An Alternate Postcondition -
Example Mapped To Use Case • The Primary Actor – The Patron • A Secondary Actor – The Library Worker • A Worker – The Librarian • A Precondition – The patron has located a book to borrow. The patron has not exceeded their limit. The patron has no outstanding fines. • A Postcondition – The patron has borrowed the book. The patron has been requested to return a book before they may borrow a book. • A Step In The Basic Flow – The librarian enters the return date into the book and hands the book with its return date to the customer. • An Alternate Flow Event – The patron has exceeded their limit of the number of books they can borrow. • An Alternate Postcondition – The patron leaves without the book.
Borrow Books Book Borrower Library Worker The Use Case Diagram The business workers live inside the use case. Patron PrimaryActor Use Case Secondary Actor
Use Case Types • Business(BUC) – Describes a story involving the interaction of people and the things they are manipulating or using. • System(SUC): • Describes a story of an interaction between an actor (could be a person or a machine) and the system being constructed. • System use cases are the result of a desire to automate parts of business use cases.
Business Use Cases • Business use cases are about people • Business use cases describe what people will do and what they need to do it. • The business use case needs to be described in such a manner that every step could be a manual step. • Business use cases are not concerned with systems.
BUC To Return A Book Exercise: • Use Case Overview: A Patron of the library returns a library book they have previously borrowed, to the library. • The Patron returns the book to the Librarian who updates the customer record to indicate that the Patron no longer has the book checked out. The library’s customer records are maintained by a Library Worker whose job it is to file, add and delete customer details as needed. • Include at least one alternative flow.
Return Book BUC • Name – Return Book • Primary Actor – Patron • Worker – Librarian • Secondary Actors – Library Worker • Preconditions – The Patron has previously borrowed a book. • Postconditions – The patron is no longer borrowing the book.
Steps In The Basic Flow • Basic Flow Steps: • The use case begins when the patron returns a borrowed book to the librarian. • The librarian requests the library worker retrieve the customer details for the patron from the library records. • The library worker hands the customer details to the librarian. • The librarian notes the returned book is checked out to the patron and changes the record to indicate that the customer no longer has the book checked out. • The Librarian hands the customer details to the library worker for filing in the library records. • The librarian informs the patron that they no longer have the book checked out. • The use case ends.
An Alternate Flow Alternate Flow 1 Precondition: Step 4 - The librarian notes that the customer details do not show the book as checked out to the patron. 1.1. The Librarian requests that the library worker search through the customer records to discover who the book is checked out to. 1.2 The library worker returns with the details of the customer that borrowed the book. 1.3 The librarian changes the details of the record to indicate that the customer no longer has the book checked out. 1.4. The Librarian hands the customers details to the library worker for filing in the library records. 1.5 The librarian informs the patron that the book was not loaned to them. Postcondition: The use case ends at step 6 in the basic flow.
A brief History Of The Use Case • 1986 - Ivar Jacobson introduces the concept of use cases to Ericsson. • 1987 – Objectory AB, founded by Jacobson. • 1995 – Rational buys Objectory. • 1995 – Use cases are introduced into the Unified Modeling Language 0.9 proposal. • 1997 – UML 1.0 adopted by OMG. • 1998 – Rational Unified Process is evolved from the Objectory process.
Break • When we come back • Revision • Activity Diagrams and • Advanced Concepts.
Revision A use case has: • Exactly one primary actor. • Zero or more secondary actors. • A name. • An overview description. • One or more preconditions. • A basic flow. • Zero or more alternative flows. • One or more postconditions. • Worker (for system use cases this is always THE system). • Extension points where functionality of the use case is described within another use case.
Activity Diagram Like a flowchart : an activity diagram includes: • Start state : The precondition to the use case. • Activity : What the worker is doing, inside the use case. • Transition : An event that causes the next activity in sequence, to execute. • Decision Box : Break points for alternate flows. • Stop State : A postcondition to the use case. • Every activity diagram has exactly one start state and at least one stop state.
Adding Alternate Flows Patron Has Book 1. Patron Returns Book 2. Requesting Customer Details 3. Details Returned [ Not Checked-Out To Patron ] Book Status? Alternate Flow 1 Precondition: Step 3 - The Librarian notes that the customer [ Checked-Out To Patron ] details do not show the book as checked out to the Patron. 1.1 Finding Who 1.1. The Librarian requests that the Library Worker search Book Is Checked To through the customer records to discover who the book is 6. Changing checked out to. Patron Record 1.2 Book Check-Out Details Returned 1.2 The Library Worker returns with the details of the customer that borrowed the book. 1.3 Changing 1.3 The Librarian changes the details of the record the indicate Check-Out Details that the book is checked-in. 1.4 The Library Worker files the updated customer records. 5. Record Updated 1.4 Record Updated The use case continues from step 6 in the basic flow 4. Filing Customer Record 7. Record Filed 8. Informing Patron That Book Is Checked-In 9. Patron Informed Book Checked-In
Parallel Activities Parallelism in a business use case: In the previous ‘Borrow Book’ example, consider the steps where the Librarian hands the book to the patron and hands the customer details to the library worker. Assume that it is not important what order these are performed. Reword Steps 5 and 6 to: 5. • The Librarian hands the patron and customer details to the library worker for filing in the library records. • The Librarian informs the patron that the book no longer loaned to them. Postcondition: The use case ends at step 6 in the basic flow. The use case ends.
Synchronization Bars • Synchronization bars allow activity flow to ‘fork’ and to ‘join’. • A fork has a single input transition and many output transitions. • A join has many input transitions and a single output transition. • Synchronization bars may be displayed vertically or horizontal.
Advanced Concepts (Include) Included use cases. • If steps in a use case are repeated in other use cases, it MAY be viable to put these into their own use case and reference them from the ‘Base’ use cases. • At whatever point in the basic flow an include occurs; the included use case should return back to the base use case at that point and the included use case ends. • Consider the steps which involve the librarian requesting customer details about the patron. This scenario occurs in several places, maybe even within the same use case. • Because the steps are repeated in several places, it makes sense to take these steps out of the use case and create an ‘included’ use case that is referenced from the appropriate steps.
Advanced Concepts (Include) • The patron is the primary actor (or initiator) in both use cases. • ‘Get Customer Record’ is the ‘included’ use case. • An included use case never has a primary actor.
Includes Flow Example • Basic Flow Steps: • The use case begins when the patron returns a borrowed book to the librarian. • The use case continues with the included steps in ‘Get Customer Record’. • The librarian notes the returned book is checked out to the patron and changes the record to indicate that the customer no longer has the book checked out. • The Librarian hands the customer details to the library worker for filing in the library records. • The librarian informs the patron that they no longer have the book checked out. • The use case ends. • Get Customer Record Use Case Steps • The librarian requests the library worker retrieve the customer details for the patron from the library records. • The library worker hands the customer details to the librarian. • The use case ends.
Advanced Concepts (Extends) Extended use cases. • If a use case contains optional (alternate) flows these may be called out as an extension to the base use case flow. • An extending use case executes its steps to completion and then ends. It does not return to the base use case. • Consider the possibility that when the library worker is requested to return a customers details that it is possible that the customer details were not found. • Since the same situation can occur in both the ‘Borrow Book’ and the ‘Return Book’ use cases, and because the action taken as a result may vary over time, it makes sense to take these steps out of the use case and create an ‘extends’ use case.
Extends Example • The patron is the primary actor (or initiator) in both use cases. • ‘Handle Missing Record’ is the ‘extending’ use case. • An extends use case does not have a primary actor.
Extends Flow Example • Basic Flow Steps: • The use case begins when the patron returns a borrowed book to the librarian. • The librarian requests the library worker retrieve the customer details for the patron from the library records. • If customer details are not found continue with the extended use case, ‘Handle Missing Records’. • The library worker hands the customer details to the librarian. • The librarian notes the returned book is checked out to the patron and changes the record to indicate that the customer no longer has the book checked out. • The Librarian hands the customer details to the library worker for filing in the library records. • The librarian informs the patron that they no longer have the book checked out. • The use case ends. • Handle Missing Records Use Case Steps: • The Library Worker is unable to locate the requested customer record. • etc... • The use case ends.
Advanced Concepts (Generalize) Generalized use cases. • A use case that contains an abstract set of steps that may be re-used by many use cases in order to describe specific actors and objects. Changing the generalization use case makes the same changes to all use cases in the relationship. • Do not recommend using the generalization relationship on use cases but, ...
Generalization Of Actors • Generalization is a very useful way of describing a use case that may have more than one primary actor. • Since the use case rules insist on one and only one, primary actor per use case, in order to show 2 primary actors, the use case has to be described twice, once for each of the primary actors, unless ... • You create an actor that is an abstraction of the two primary actors, and use the generalization relationship to indicate that the two actors are instances of the abstract actor. • Now connect the abstract actor to the use case that they have in common to indicate that the use case can be initiated by either type of actor.
Benefits Of Business Use Cases • Captures the desired behavior without describing how to implement it. • An easy to understand notation for communicating behavior. • Used to verify that requirements have been captured. • Used to plan projects.
The Use Case Model • The use case model is a complete set of use cases that describe a complete business vision, or encompass the complete set of requirements for a system. • A use case model includes all use cases, their specifications, interfacing actors and relationships. • The use case diagrams give a pictorial view of the use case model. • Activity Diagrams give a pictorial view of the use case.
Summary • Find more information at: • Use Cases – Yesterday, Today and Tomorrow, by Ivar Jacobson • An introduction To Use Case Analysis, by Richard Woolridge. • A Brief Guide To UML Distilled, Martin Fowler. • 10 Ways To Misuse Use Cases, Ellen Gottesdiener, EBG Consulting, Inc. • Managing Use Case Details, Kurt Bittner. • Use Case FAQs and Answers, Kurt Bittner. • Writing Effective Use Cases Overview, Alistair Cockburn. • Rational Web Site contains many articles on use cases. • Introduction To UML, Terry Quatrani.
