introduzione ai casi d’uso adriano comai 1999 pag. 1 use cases: an introduction adriano comai...

Introduzione ai casi d’uso Adriano Comai 1999

Pag. 1www.analisi-disegno.com

Use Cases: an Introduction

Adriano Comai 1999



Goals of this Introduction

• To provide basic information about use cases

• To provide suggestions about their use in application development

• These points are treated in more depth, with exercises, in the course “Requirements and Use Cases Definition”:

http://www.analisi-disegno.com/a_comai/corsi/sk_req.htm



Use Cases

• Proposed by Ivar Jacobson (book published in 1992)

• New terminology, but a long practised technique (study of operational scenarios of system usage)

• Use cases are the “ways” in which a system can be used (the functions which the system provides to its users)



Use Case : Point of View

• It starts usually with a request from an actor to the system

• It ends with the production of all the answers to the request

• It defines the interactions (between system and actors) related to the function

A use case describes a function from the point of view of its users:

The point of view to take into account must be the actor’s, not the one of the system



Use Cases vs (Internal) Functions

Use Cases

• call someone

• receive a call

• send a message

• memorize a number

• ….

Point of view: USER

Internal Functions

• transmit / receive

• energy (battery)

• user I/O (display, keys, ...)

• phone-book mgmt.

• …..

Point of view: DESIGNER



Use Cases vs (Internal) Functions

Internal functions• specialized front-ends

• common front-end

• pre-application controls

• contract management

• system monitoring

Use Cases

• customer:– orders (payment, buy

stocks, etc.)

– inquiries

– contract

• administrator:– verify anomalies

customer banking systems

administrator

electronicbanking



Use cases as Interaction

• Use cases can be described as an interaction scenario (a dialogue) between the users and the system:– customer asks for a list of products

– system shows available products

– customer chooses products she wants

– system shows total cost of selected products

– customer confirms order

– system communicates acceptance of order

• Attention must be given to the interaction, not to internal system activities



Use Cases Identification

1 Identify system users (“actors”)

2 (For each actor) discover in which ways the actor will use the system, starting from the goals the actor has to achieve

3 (For each use case) clarify how the the activity starts, the answers the actors expect from the system, the sequence of the interaction

Use cases help to discover requirements



Requirements and Use Cases

(functional) requirement : a function, or a characteristic of a function, requested by the customer or by some other stakeholders of the system

use case: a way the system can be used by a user (actor)

• Each use case can satisfy many functional requirements

• A functional requirement can be related to many use cases

• Each use case can have many non-functional requirements associated to it



Prototype and Use Cases

• For each use case there is an interaction between actors and system, realized through interfaces

• It is a good idea to prototype the interaction (especially between system and human beings) during use case definition :

– use case and prototype are complementary ways to depict the interaction

– UI prototype helps to clarify use case sequence

– use case description helps to discover needed links between interfaces



Use Case (Jacobson’s Definitions)

• (in a business system): “A sequence of transactions in a system whose task is to yield a result of measurable value to an individual actor of the business system”

• (in an information system): “A behaviourally related sequence of transactions performed by an actor in a dialogue with the system to provide some measurable value to the actor”(Jacobson 1995)



Use Cases and Transactions

Each use case can be implemented by a sequence of transactions in the system, in order to provide the aswers needed by the actor

customer open account

Transactions:* verify existence of customer in DB* insert new customer* scan signature of customer* insert new account



Actors

• Entities interacting with the system, through messages

• Actors can be:

– human beings

– organizations

– other systems (both hardware and software)

• Each actor is a class, and may have many instances– Ex. Actor “customer” is a class; every individual customer is a

member of the class



“Business Actors” vs. “Information System Actors”

A model independent from any organizational and technological solution

Order Clerk places an order

The model of a specific organizational and technological solution

Customer places an order



“Business Actors” vs. “Information System Actors”

• Independent from specific organizational and technological solutions (“Business Model”)

• Dependent on a specific organizational and technological solution (“Information System Model”)

Actors can be defined following two points of view, both important and legitimate, corresponding to two different levels of abstraction :



Business / IS Model

From the point of view of the customer, the order clerk is a part of the system (as a mediator, an interface)

customer

places an order

administration

order clerk



Mediation Forms

• The interface between actor and system changes• The logic core does not change

customer

request of statement of account

phone

clerk

internet

ATM



Mediation Forms

• “human” interface:• pros: flexibility, able to adapt to the specific actor• cons: cost, absence of uniformity

• “automated” interface:• pros: cost, uniformity• cons: not able to understand requests that are

either not-predefined, or specified in an unexpected way



Use Cases and Scenarios

• Base Scenario : (usually) implies success, and a linear development of the use case

• Alternate Scenarios : can imply success or failure, with various complications

• we do not need (it would be very expensive) a detailed analysis of every possible use case scenario (combination of variances)

• but we must discover every variance that can bring to the failure of the use case, or that needs a specific treatment



example: open account

1 Customer goes to the bank to open an account2 Clerk welcomes customer and gives explanations3 If customer accepts rates she gives her personal info4 Clerk verifies if customer is already known to the bank5 Clerk opens a new account

6 Clerk gives the customer an account number

Variances:3 (a) If customer does not accept, use case ends3 (b) If the account is opened by many people, it is necessary to give

personal info of every holder

4 (a) If customer (one of the set of customers) is not known, clerk registers her,asks for the signature, scans the signature



example: open account - more detail

(5) Clerk opens a new account

1 Clerk starts transaction “open account”

2 System asks customers’ codes

3 Clerk inputs codes

4 System shows corresponding personal info, and asks for rates

5 Clerk inputs rates, and confirms

6 System prints contract, with new account number

Variances:

3 (a) if system does not know a customer, or displays unexpected data, clerk can correct or stop the transaction



Use Case Levels

Use cases are a specific way to represent functions, and they can describe objects at different levels:

• system

• subsystem

• component (or class)

Whatever the level, use cases define a behaviour of the object they describe, without revealing its internal structure



Use Cases at the “Business Event” Level

• Update Web catalog

• Customer Info Request

• Customer Order

• Payment

• Assistance Request

It is possible to identify and describe use cases at the level of events triggered by actors (each use case implies every needed answer to the event):



Use Cases at the “Transaction” Level

• Create Order

• Read Order

• Update Order

• Delete Order

It is possible to identify and describe use cases at the level of each transaction, down to the point of atomic operations (CRUD) on the classes of the system:



From which Level to Start?

For a medium-sized system we can have:

• about a dozen use cases at the “business event” level– complete functions from the point of view of actors

– meaningful delivery (and system test) units

• more than one hundred use cases at the “transaction” level– internal system functions

– can be too fragmented to be used as a basis of understanding between designers and with system customers



Use Case Role

Requirements Use case:Customer Order

Seller

Customer

Ordine

DataArrivoNumeroPrezzo

verifica( )evadi( )

Cliente

nomeindirizzo

StabilisciCredito( )10..*

Analysis & Design Models

Test cases

Delivery Units



Are Use Cases OO?

• Were “Invented” in an Object Oriented context

• Describe system functions from the point of view of the external actors (like OO messages)

• Do not reveale the internal structure of the system

• Are the best starting place for OO design

…but…

• Can be used in a non-OO development process

• OO theory is not needed to understand and to use them



Use Cases Implementationrequirements

use cases

components

object oriented analysis anddesign

structuredanalysis anddesign

other methods (as you prefer)

buycomponents

introduzione ai casi d’uso adriano comai 1999 pag. 1 use cases: an introduction adriano comai...

Documents

use cases customer

interaction use cases

system slide

use cases definition

use cases identification

order system

system users actors

introduction adriano