Introduzione ai casi d’uso  Adriano Comai 1999 Pag. 1 Use Cases: an Introduction  Adriano Comai 1999

Introduzione ai casi d’uso  Adriano Comai 1999 Pag. 2 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”:

Introduzione ai casi d’uso  Adriano Comai 1999 Pag. 3 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)

Introduzione ai casi d’uso  Adriano Comai 1999 Pag. 4 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag. 5 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag. 6 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 electronic banking

Introduzione ai casi d’uso  Adriano Comai 1999 Pag. 7 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag. 8 Use Cases Identification 1Identify 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag. 9 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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)

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag “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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag “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 :

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag example: open account 1Customer goes to the bank to open an account 2Clerk welcomes customer and gives explanations 3If customer accepts rates she gives her personal info 4Clerk verifies if customer is already known to the bank 5Clerk opens a new account 6Clerk gives the customer an account number Variances: 3(a) If customer does not accept, use case ends 3(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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag example: open account - more detail (5) Clerk opens a new account 1Clerk starts transaction “open account” 2System asks customers’ codes 3Clerk inputs codes 4System shows corresponding personal info, and asks for rates 5Clerk inputs rates, and confirms 6System 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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):

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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:

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag Use Case Role Requirements Use case: Customer Order Seller Customer Analysis & Design Models Test cases Delivery Units

Introduzione ai casi d’uso  Adriano Comai 1999 Pag 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

Introduzione ai casi d’uso  Adriano Comai 1999 Pag Use Cases Implementation requirements use cases components object oriented analysis and design structured analysis and design other methods (as you prefer) buy components