Use Cases 1

UMLBasic Behavioral Modeling

Part I

Use Cases 2

UML Bird’s Eye View

Building Blocks:

Things: abstractions, main concepts in a model

Relationships: tie the things together

Diagrams: group interesting collections of things

Use Cases 3

Things in the UML Structural Things (7)

static part of a model, conceptual or physical elements

nouns of UML Models

Behavioral Things (2)

dynamic parts of models

verb, representing behavior over time and space

Grouping Things (1)

Organizational parts of models, decomposition element

Annotational Things (1)

explanatory parts of models, comments about other elements

Use Cases 4

Relationships in the UML Dependency

semantic relationship, a change in one element may affect the other element

Association

structural relationship that describes a set of links among objects

Generalization/Specialization

relationship in which objects of the specialized element (child) are substitutable for objects of the generalized element (parent)

Realization

semantic relationship between classifiers (class realizes an interface or collaboration realizes a use case)

Use Cases 5

Diagrams in the UML• Class diagram• Object diagram• Use case diagram• Sequence diagram• Collaboration diagram• Statechart diagram• Activity diagram• Component diagram• Deployment diagram

Use Cases 6

Rules of the UML

UML defines Rules for

Names

Scope

Visibility

Integrity

Execution

Use Cases 7

Common Mehanism in the UML

Specifications

Adornments

Common Division

Extensibility Mechanisms

Use Cases 8

Behavioral Modeling

Use Cases / Use Cases Diagrams

Interactions / Interaction Diagrams

State Diagrams

Activity Diagrams

Use Cases 9

Use Cases

Description of a set of sequences of actions, that a system performs to yield an observable result to an end-user

Categories of interactions between the system to be built and external actors

Identify high-level services provided by the system

Specify the behavior of a system

Popularized by Ivar Jacobson with Objectory

Have been adopted by or have influenced many methods (eg. OMT, Fusion, Booch)

Use Cases 10

Use Cases (cont.)

Can be applied to whole system as well as part of system such as a subsystem or a class

Sources of integration tests and system tests

May have variants: specialized use cases or extension of use cases.

Do not specify any implementation detail

Main communication tool with end-user

Each use case must have a name (simple or path name)

Use Cases 11

Actors Objects outside the system which play a particular

role

Represent the user(s) of the system

Interact with the system through use cases

May participate in more than one use case

May or may not be represented as a class or object in the object model

Also known as agents (Jacobson)

Use Cases 12

UML Use Case Graphical Representation

Delivery

Collection

StatusClerk

Manager

Storage depot system

Storage

Actor

Use case

Use Cases 13

Why Modeling Use Cases Use Case model describes WHAT the system will do at a high-level

User focus - Capture requirements from user's perspective. - Users are involved.

Goal is to scope the project and give the application some structure

- Use Cases are the unit of estimation - Uses Cases are smallest unit of delivery- One way of estimating the percentage of requirements

captured. - Prioritizing use cases for "phased delivery" according to

user's immediate needs. - Better way of estimating the percentage of requirements

completed during development

Use Cases 14

Benefits of use cases Good way to start identifying objects from scenarios.

Test plan can be immediately generated based on use cases.

Easier user validation.

Helps technical writers in structuring the overall work on the users manuals at an early stage.

Better traceability throughout the system development process.

Quality of the software is improved by identifying the exception scenarios earlier in the development process.

Use Cases 15

Problems with use cases

What is the right granularity

What is a correct Use Case

Explosion of different scenarios

Focus on functions, with potential for functional decomposition

Too often too informal

Use Cases 16

Use Cases and Scenarios

Scenario is a specific sequence of actions

Scenario is one instance of a Use Case

Typically many scenarios correspond to one Use Case

Example:

Use Case = Hire Employee

Scenarios- Hire at Job Fair- Hire through newspaper ad- Hire from internal promotion- Hire Temp

Use Cases 17

Use Cases and Collaborations

Use Case captures WHAT the system does

Use Cases do not specifies HOW the System does it

Development effort is aimed at implementing the use cases by creating a society of classes working together

These interacting classes are modeled using Collaborations

A Collaboration is the realization of a Use Case

A Collaboration represents how responsibilities are distributed across objects

A Collaboration has a Static and a Dynamic aspect

Use Cases 18

Organizing Use CasesRelationships: Generalization, Include (Use) and Extend

Generalization:– Like for Classes

Include: - Use: Contains another complete use-case

Extend:- Extends another use-case- used for optional separate flow (exception)

Beware: - Over-use of extends = functional decomposition - Rumbaugh says Use = aggregation and Extend

= inheritance

Use Cases 19

Hints and Tips

• Each Use Case should represent a single, identifiable and reasonably atomic part of the behavior of the system

• Factors Common Behavior by pulling such behavior from other use cases that it includes

• Factors variants by pushing such behavior into other use cases that extend it

• Describe flow of vents clearly enough for anyone to easily understand it

• Each Use Case is described by a number of scenarios that specify the normal and variants

Use Cases 20

Use Case Diagrams

system is represented by a large rectangle

uses cases are represented as ellipses within the system rectangle

actors are represented as stick figure outside the system

an arrow connects the initiating actor to the use case (ending at the use case)

other participating actors are joined by arrows terminating at the actor

Use Cases 21

Banking System Use Case Diagram

open_account

withdraw_cash

loan_application

clear_checks

get_report

Customer

Manager Loan Officer

Clerk

Cash Dispenser

Use Cases 22

Use Case Identification Steps

•Determine the boundary of the system- consider system as a single “black box” object

•Identify who is going to be using the system directly - e.g. hitting keys on the keyboard. These are the Actors

- start by considering physical object-an individual object may play several roles

•Choose One of these Actors and determine the fundamental ways in which each actor uses the system

-each of these is a use case-must be enumerable- for each of those Use Cases decide on the most usual course when that Actor is using the system. What normally happens. This is the basic course

Use Cases 23

Use Case Identification Steps (2)• Describe it as "Actor does something, system does something. Actor does something, system does something." but keep it at a high level.

do not mention any GUI specifics

only describe things that the system does that the actor would be aware of and conversely you only describe what the actor does that the system would be aware of.

do not worry about the alternate paths (extends) or common courses (uses) - Yet -

• Review each Use Case descriptions against the descriptions of the other Use Cases.

•Once basic course is OK, consider the alternates and add those as extending use cases.

Use Cases 24

Use Case Identification Steps (3)

•Good way of getting started with Use Case modelling.

•Once started and comfortable with this process, next step:

understand the trade-offs that can be made

simplicity versus "completeness"

putting too much in is the most common mistake.

Use Cases 25

Use Case Textual Descriptions

- a clerk requests the system to create a new account

OPEN_ACCOUNT

WITHDRAW_CASH

CLEAR_CHECKS

LOAN_APPLICATION

GET_REPORT

- a customer requests the system to withdraw a specified amount of money from a specified account

- a clerk instructs the system to update all accounts according to specified transactions including checks

- a customer files a loan application

- a manager or loan officer requests a report of the days transactions from the system

Use Cases 26

Use Cases Diagram Hint and Tips

• Put all the Use Cases that describe one aspect of the system together

• Contains only those use cases and actors essential to understanding that aspect

• Diagram should be named to communicate its purpose

• Minimize crossing lines

• Don’t draw too many use cases or too many relationships in one diagram

Use Cases 27

Modeling Exercices:

• Develop the Use Cases for a Telephone Catalog System

• Develop the Use Cases for a Point Of Sales System grocery store requires a computer system to control the

checkout points at which customers pay for the items they have selected. Using the bar code the checkout controller determine the price, name, number in stocks, sell-by-date (if applicable)

• Develop the Use Cases for a Access Control System

System maintains the security and access t a number of doors inside or into a building. Doors are linked to keypads and card reader. All doors are connected to a central controlling unit

•Develop the Use Cases for a Course Scheduling System

Use Cases 28

Modeling Exercices:

•Develop the Use Cases for a Library System

supports library

library lends books and magazines to borrowers who are registered in the system, as are books and magazines

library buys new titles, eventually in multiple copies

old books and magazines are removed when out of date.

borrower can reserve a book or magazine not currently available

Use Cases 29

Detail Use Cases

• Start with a short, step-by-step description of the use-case flow of events, and gradually make it more detailed.

• Describe how the use case start and what is the signal that activates the use case.

• Describe how the use case terminate

• Describe what will reside inside the system, and what will reside outside the system.

• Describe the interaction between use case and actors.

• Describe how the use case exchange data with an actor.

Use Cases 30

Use Case Details Name

The name of the use case.

Brief Description

A brief description of the role and purpose of the use case.

Flow of Events

A textual description of what the system does in regard to the use case. Understandable by the customer. Include the main flow of events as well as the alternate flow of events

Special Requirements

A textual description that collects all requirements, such as non-functional requirements, on the use case, that are not considered in the use-case model, but that need to be taken care of during design or implementation.

Use Cases 31

Use Case Details Preconditions

A textual description that defines the state of the system prior to the use case may being performed.

PostconditionsA textual description that defines a list of possible states the system can be in immediately after a use case has finished.

Extension pointsA list of locations within the flow of events of the use case at which additional behavior can be inserted using the extend-relationship.

RelationshipsThe relationships, such as communicates-associations, include-, generalization-, and extend-relationships, in which the use case participates.

Use Cases 32

Use Case Details - Example Name :

Register for Courses

Description:

This use case is started by the actor student. It provides the capability for the student to manage his registration to a course for a semester, and to have the billing information sent to the Billing Office.

Main Flow of Events:

The student enters his Id.

The system verifies the student Id, and prompt the student to select the current or a future semester.

The student selects the semester.

The system prompts the student to select the desired activity (create a registration, review a registration, change a registration).

Once completed the student indicates that the activity is completed.

The system acknowledge and displays the result of the activity.

The system sends the billing information to the billing system for processing.

Use Cases 33

Use Case Details – Example (cont.) Alternative Flow of Events:

1- If an invalid Id is entered, the system will not allow access to the registration system and displays an error message to the student.

Special Requirements:

The student should be able to access the system through the web. It should take less than 30 seconds to display the web page. A student can register to a maximum of 5 courses per semester.

Pre-Conditions:

The system is operational.

Post-Conditions:

The student information has been updated. His bill is sent.

Extension Points:

None

Relationships:

None