use cases. applying uml and patterns :craig larman applying uml and patterns

Use cases

Applying UML and Patterns :Craig Larman

Applying UML and Patterns

http://www.craiglarman.com/wiki/index.php?title=Image:Applying_uml_3e.jpg

Object-Oriented Analysis and Design

Overview

• Use cases describe domain processes in a structured prose format.

• We explore basic skills.– Definitions.– Notation.– Guidelines.– Practice.

N


Objectives

• Read and create high-level and expanded format use cases.

• Distinguish between essential and real use cases.


Use cases

• They are used to discover and record requirements.

• Use cases are not diagrams they are text documents.

• Use cases are one way of capturing the functional requirements.

• Use cases are text stories of some actors using a system to meet goals.


MOTIVATION: Comprehensible & Familiar

• Use cases are stories.

• A simple and familiar model that many people, especially non-technical, can easily relate to.


Use Cases• They are a collection of related success and

failure scenarios that describe an actor using a system to satisfy a goal.

• They must return an observable value to a particular actor.

B orrowR esources


scenarios

• A scenario is also called a use case instance.• It is a specific sequence of actions and

interactions between actors and the system. orIt is one path through the system.


Actor

• An actor is someone with behavior.• Think of actors in terms of Roles rather than

job titles.• Actors carry out use cases.• A single actor carries out many use cases and

many roles.• There is one Primary actor and possibly

several secondary actors.


ActorsActors can be:

• Roles of humans.Example: A Patron.

• Other computer systems.Example: The Visa network.


The three Common formats for Use cases.

• Brief: One paragraph summary of the main success scenario.

• Casual: multiple paragraphs that covers various scenarios.

• Fully dressed: All steps and sections are written in detail, and there are supporting sections such as preconditions and success guarantees. Also known as the expanded format.


Brief Use CaseName: Borrow Resources

Actors: Patron (initiator), Librarian

Description: The use case begins when the Patron arrives at the check-out with books and videos to borrow and submits them to the Librarian, who records the resources borrowed. The Patron then leaves with the resources.


Use Case DiagramsLibrary Inform ation System

Librarian Patron

B orrowR esources

R eturnR esources

A ddR esources


Sample High-Level Primary Use Cases

Name: Add Resources.Actors: Librarian.Description: The use case begins when the

Librarian receives new resources (books and videos) to add to the catalog. The title,

call number, and other information are recorded. Then the resources are placed on a shelf organized by resource type and

call numbers.


Sample High-Level Primary Use Cases Other possible use cases.

• Return a Resource.

• Delete a Resource.

• Notify Overdue Patrons.

• Collect Fines.


GUIDELINES: Use Case Modeling

• It is common to group CRUD (Create, Read, Update, Delete) operations into one use case.– Manage Users

• Name starts with a verb.Manage Users

• All systems have a Start Up and Shut Down use case (perhaps trivial and low level).


Abstraction Levels of Use Cases

ESSENTIAL

REAL

The essence of the process. Analysis-oriented.

Concrete, design-oriented.

Expresses process (relatively) independent of a hardware/software solution.

Essential use cases defer the details of the UI, and focus on the intentions of the actors.

Clerk enters Customer ID.

Expressed in terms of the solution—screen shots of windows, entry into input fields, and so forth. Clerk takes Customer ID card and reads the bar code with laser scanner.


Essential versus Real Use CasesEssential Real

The Librarian records the callnumber.

The Librarian uses the laserwand to scan the bar code forthe call number, which istransmitted to the computer.

The AccountHolder identifieshimself to the ATM.

The AccountHolder insertsthe card into the ATM cardreader. He is prompted toenter his PIN (see screenshot 4), which he inputs with anumeric keypad.


Expanded Format Use CasesDescribe the use case in greater detail. Can be written essential or real.Have the following components:

◦Name. Starts with a verb.

◦Description. From the high-level use case.

◦Actors. Initiator and participants from high-level use case.

◦Type. If decomposed, then super / sub (abstract). Also, primary / secondary, and essential / real.


Expanded Format Use Cases (continued)

Have the following components (continued):◦ Cross-references.

Related use cases and system functions.◦ Preconditions.

Assumptions that must hold true.o Stakeholders and their interests.

◦ Typical Course of Events. Most important section describes regular flow of events.

◦ Alternatives. Exceptional alternatives that might arise.o Special requirements. : related non-functional requirements.o Technology and data variationo Frequency.o Open Issues.


EBP for Use Case Levels• Focus on use cases at the level of EBPs.

– “A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.”

• Naively, can you apply the “boss test” for an EBP?


Here’s one in a brief format:

– Rent Videos. A Customer arrives with videos to rent. The Clerk enters their ID, and each video ID. The System outputs information on each. The Clerk requests the rental report. The System outputs it, which is given to the Customer with their videos.


EBP for Use Case Levels• For example, how do we know which of these is at a useful level?

– Negotiate a Supplier Contract– Rent Videos– Log In– Start Up

• Boss: “What do you do all day?”

• Me: “I logged in!”

• Is Boss happy?


Size for Use Case Levels• An EBP-level use case usually is composed of several

steps, not just one or two.• It isn’t a single step.

• Applying the EBP and size guidelines:

– Negotiate a Supplier Contract– Rent Videos– Log In– Start Up

• The others can also be modeled as use cases. – But, prefer a focus on the EBP level.


Use Case DiagramsVideo Store

Information System

Administrator

ManageInventory

ManageMemberships

Clerk

Customer

«actor»Credit

AuthorizationService

Pay Fines

Rent Items

Log In

Manage Users


GUIDELINES: Use Case Diagrams

Video Store Information System

Rent Videos

. . .Clerk

Show computer system actorswith an alternate notation tohuman actors.

primary actors onthe left

supporting actorson the right

Prefer use cases at the EBP level.

«actor»Credit

AuthorizationService


EXAMPLE: Fully DressedUse Case UC1: Rent VideoLevel: User-level goal (EBP level) Primary Actor: ClerkPreconditions: • Clerk is identified and authenticated.

Stakeholders and their Interests:Clerk: Wants accurate, fast entry.Customer: Wants videos, and fast service with minimal

effort. Accountant: Wants to accurately record transactions.Marketing: Wants to track customer habits.


EXAMPLE: Fully DressedMain Success Scenario (or Basic Flow or “Happy Path”):

1. Customer arrives at a checkout with videos or games to rent.2. Clerk enters Customer ID.3. Clerk enters rental identifier.

4. System records rental line item and presents item description.(Clerk repeats steps 3-4 until indicates done.)

5. System displays total.

6. Customer pays. System handles payment.

7. Clerk requests rental report.

8. System outputs it. Clerk gives it to Customer.

9. Customer leaves with rentals and report.


EXAMPLE: Fully Dressed

Extensions (or Alternatives):a*. At any time, System fails:

1. Clerk restarts System2. logs in3. requests recovery from prior state

1a. New Customer. 1. Perform use case Manage Membership. 2a. Customer ID not found. 1. Cashier verifies ID. If entry error, reenter, else Manage Membership.2b. Customer has unpaid fines (usually for late returns). 1. Pay Fines.


EXAMPLE: Fully Dressed

Special Requirements: Language internationalization on the display messages and rental

report. Large text on display. Visible from 1 m. Technology and Data Variations: ID entries by bar code scanner or keyboard.

Frequency: Near continuous

Open Issues: Should we support a magnetic stripe cards for customer ID, and

allow customer to directly use card reader?


Librarian

B orrowR esources

Use-Case Miscellany

The first line of a use case course of events should describe the event that starts the use case.◦Example: This use case begins when the <actor>

<generates an input event>Start the use-case name with a verb.

◦Purchase …◦Borrow …


generalization

– A use case generalization shows that one use case is simply a special kind of another.

– A child can be substituted for its parent whenever necessary.

– Generalization appears as a line with a triangular arrow head toward the parent use case.


Include relationships

• Includes are especially helpful when the same use case can be factored out of two different use cases.

• In the diagram, include notation is a dotted line beginning at base use case ending with an arrows pointing to the include use case. The dotted line is labeled <<include>>.


extend relationship

• An extend relationship indicates that one use case is a variation of another.

• Extend notation is a dotted line, labeled <<extend>>, and with an arrow toward the base case.

• The extension point, which determines when the extended case is appropriate, is written inside the base case.

use cases. applying uml and patterns :craig larman applying uml and patterns

Documents