9/10/2004 Use Case Workshop 1

CSC480 Software Engineering

Workshop 1

Requirements Modeling

Use Case Workshop 29/10/2004

Requirements Modeling

Use cases Context diagrams Actors Use case formats Use case lists Scenarios

Exercises

Use Case Workshop 39/10/2004

Why Do Analysis & Design?

Communicating with Domain Experts Communication within the development team Learning OO

Imagine the scenario in which a customer needs a music box.

Use Case Workshop 49/10/2004

Basic Rules

Analysis answers the What-questionDesign answers the How-question

Never do design before analysis Start from a clear description of the concept and

think naturally Communicate with your partners intensively Analysis and design are iterative and creative

processes: don’t obsess over perfection

Use Case Workshop 59/10/2004

Analysis Activities

Use Case Workshop 69/10/2004

The Restaurant Example

Buys lunch

Buys dinner

Delivers supplies

A cto rGuest

A cto rSupplier

System border

Actor

Usecase

Restaurant

Use Case Workshop 79/10/2004

The Buys Lunch Use Case

Basic course of actionsA. The Guest entersB. The Guest may leave his/

her coat to the cloakroomC. The Guest is shown a tableD. The Guest makes an orderE. The food is prepared in the

kitchen and beverage picked from the refrig.

F. The food is served to the table

G. The Guest pays the billH. The guest gets his/her coat

and leaves

Alternative courses of actions Alternative I: if the restaurant

is full, the Guest can wait in the bar (to be continued at stage B) or leave (use case completes).

Alternative II: if the dish that the Guest ordered is not served that day, the waiter should recommend an alternative. The use case continues at stage E when the Guest’s decided on sth.

Use Case Workshop 89/10/2004

Scenarios or Alternatives

Scenario 1.1.1 Guest get desired selection: no problem Scenario 1.1.2 Restaurant is full: guest waits in bar Scenario 1.1.3 Restaurant is full: guest leaves Scenario 1.1.4 Desired selection unavailable: guest

makes alternate choice; guest gets alternate

Use Case Workshop 99/10/2004

Any User PSP Tools

1. Select Open ...

2. Specify a project database and select OK.

3. Open the project database. If an error occurs, display an appropriate error message and end this use case.

4. Enter the user name and optional password and select Login. Select Cancel to end this use case with no state change.

5. Ensure that the username and password (if present) are for an existing member of the database. If not, display an appropriate message and allow the user to be added to the database. If the PSP User decides not to add the new user, end the use case; otherwise, proceed with Alternate Flow of Events: Add New User to Project Database. If there is an existing user, proceed with the next step.

6. Make the database the current database for the user. Close any open database. Display the appropriate view of the data in the project database for this user.

Another Format

Use Case Workshop 109/10/2004

Relationships: extend and include

Buys dinner

A cto rGuest

Buys a starterBuys dessert

Buys candlelight dinner

Buys lunch

Buys dinnerA cto rGuest

Buys candlelight dinner

<<extend>>

<<include>>

<<include>>

<<extend>><<extend>>

Use Case Workshop 119/10/2004

Use Case

A definition by the inventor

A use case is a sequence of transactions between the system and an actor yielding a result of measurable value for the actor.

Ivar Jacobson

Use Case Workshop 129/10/2004

Why Use Case?

A good tool to model what perspective users want and need Someone or something interact with the system The system performs a sequence of actions in

response All the use cases together provide a complete answer

to: What is the system supposed to do for each user?

The use cases drive the development process

Use Case Workshop 139/10/2004

RUP is use-case -driven

Use Case Workshop 149/10/2004

Use Cases: our sources

Domain Expert / Subject Matter Experts Problem statement Specification Documentation System users

“Day in the Life ...”

...

Use Case Workshop 159/10/2004

Use Cases: our tasks

How to capture and describe The “System” The “Actor(s)” The “Sequence of transactions” between the system

and the actor(s) The “Result of Measurable Value” for the actor(s)

Use Case Workshop 169/10/2004

The Problem: a vending machine

Design a program that simulates a vending machine. Products can be purchased by inserting the correct number of coins into the machine. A user selects a product from a list of available products, add coins, and either get the product or gets the coins returned if insufficient money was supplied or if the product is sold out. Products can be restocked and money removed by an operator.

Use Case Workshop 179/10/2004

Exercise I: Establish the Context

Identify the Actors Identify their inputs to and outputs from the

system Construct a context diagram

Use Case Workshop 189/10/2004

One Way To...

Capture and describe the “System” Use Context Diagram

System

A cto rActor 1 A cto rActor 2

Input

Output

Input

Output

Advantage: forces focus on system-level I/O Disadvantage: enterprise concept not shown

Use Case Workshop 199/10/2004

Capture and Describe the “Actors”

“Actors” vs “roles” vs “people” Originally meant “role” (a mistranslation from Swedish) An actor usually represents a person in a certain role Another system interacting with the system of concern

may also be an actor

Primary vs Secondary actors It’s possible that multiple actors might be involved in

one use case The actor starting the use case is considered primary

Use Case Workshop 209/10/2004

Use Cases: our tasks

What’s left? The “Sequence of transactions” between the system

and the actor(s) The “Result of Measurable Value” for the actor(s)

Approach it in this order: do “ ... value” 1st Ties to system level requirements Easier: “Sequence of transactions” is time consuming

Use Case Workshop 219/10/2004

Heuristics: Use Case

Name use cases as “Actor verb Object” Object is a class in model

Guest buys Dinner Teller cashes Check

Write in terms of things that will become candidate domain objects (classes)

Can be used to divide workload among (teams of) developers or planning iterations

Use Case Workshop 229/10/2004

Organize Use Cases

Use the use case diagram Use a use case list

Actor 1 Use case 1.1 name Use case 1.2 name ...

Actor 2 Use case 1.1 name Use case 1.2 name ...

...

Use Case Workshop 239/10/2004

Exercise II: Identify Use Cases

For each of the actors identified in Exercise I, identify their use cases via a Use Case Diagram

Use Case Workshop 249/10/2004

Heuristics: Selecting Use Cases

Begin with the key actor Select the key use case

Most important to the success of the project Represents customer satisfaction if completed

Not necessarily most obvious; maybe most common Completion of this use case represents a measurable,

significant part of the system requirements Implementation of the depth before the breath

Use Case Workshop 259/10/2004

Exercise III: Document Key Use Case

Identify the key actor Identify the key use case Provide a description for the key use case