modelo&de&casos&de&uso&(usecases) && (análise&de… ·...

1

© Ana Moreira

© Ana Moreira

Modelo de casos de uso (use cases) (análise de requisitos)

•  Um caso de uso descreve como o sistema será usado – descreve a essência do sistema na perspec9va dos u9lizadores

•  Um diagrama de casos de uso ilustra essa essência visualmente

•  Um modelo de casos de uso descreve a essência do sistema segundo a visão dos u9lizadores –  descrição de use cases –  definição das interacções entre o sistema e os atores

•  Meio de comunicação entre o engenheiro de soAware e o u9lizador

2

© Ana Moreira

Modelo de use cases: sistema, actors e use cases

•  Decomposição funcional do sistema em use cases e respec9vos atores – use cases representam os requisitos dos u9lizadores

– atores são en9dades externas que interagem com o sistema

•  Construção do modelo de use cases – diagrama de use cases global – descrição detalhada de cada use case

© Ana Moreira

Modelo de use cases: conceitos •  Ator: papel desempenhado por um u9lizador, SW ou HW.

•  Use case (caso de uso): –  diálogo que mostra uma sequência de transacções

entre o sistema e o u9lizador

–  descreve cenários de u9lização do sistema –  foca uma funcionalidade completa (visão op9mista e

situações de erro)

•  Os casos de uso são usados no levantamento de requisitos; eles cons9tuem a base para a análise, desenho, testes e implementação.

3

© Ana Moreira

Modelo de use cases: um exemplo

Considere um sistema de reciclagem de garrafas, latas e grades. Como cada item tem dimensões e preços diferentes, o sistema tem que iden9ficar que 9po de item acabou de receber. O sistema regista o número de itens e, se o cliente pede um recibo, imprime o número de itens devolvidos, o seu 9po e os preços parciais e o total que será depois pago ao cliente. O sistema também é usado por um operador que, ao fim do dia, pede uma listagem dos itens devolvidos nesse dia. O operador pode ainda mudar informação no sistema.

© Ana Moreira

Quais os atores e os casos de uso? •  Atores: cliente e operador. •  O cliente pode:

 Devolver itens. Isto forma o use case “Devolver Item”.

•  Este use case inclui tudo desde a devolução do item até à impressão do recibo.

•  O operador pode:  Pedir listagem diária. Isto forma o use case “Gerar relatório diário”.

 Modificar informação. Isto forma o use case “Modificar item”.

Devolver item

Gerar relatório diário

Modificar item

Cliente Operador

4

© Ana Moreira

Descrever casos de uso

•  Cada caso de uso TEM que ser descrito mais detalhadamente

•  Eis uma descrição textual para “Devolver item” (complete você com a descrição dos casos de erro):

Devolver item é iniciado pelo cliente quando quer devolver garrafas, latas ou

grades. Por cada item inserido na máquina, o sistema incrementa o número de

itens devolvidos pelo cliente e ainda o número diário total de itens daquele

9po. Quando o cliente já não tem mais itens para devolver, pede um recibo

carregando no botão de recibos. O sistema faz os cálculos necessários e, por

cada 9po de item devolvido, calcula o preço e o número de itens devolvidos.

Esta informação é imprimida, um item por linha, por uma impressora.

Finalmente o sistema calcula o valor total e a impressora imprime-‐o. Sempre

que ...<complete com as situações de erro>

© Ana Moreira

Modelo de casos de uso

•  Casos de uso são simples (são vizualmente simples), mas idenMficar os que interessam e descrevê-‐los correctamente é diOcil

•  O modelo de casos de uso é o modelo mais importante que você pode criar – Porque explicitar, reconhecer e organizar os objec9vos é fundamental para os conseguir a9ngir

– “Uma viagem de milhares de Km começa com um passo” [Lao Tzu]

– “Se você não sabe onde vai, a jornada não terá fim”

5

© Ana Moreira

Descrever casos de uso

•  Qual a diferença entre um caso de uso e um método/operação de uma classe?

•  Formas de iden9ficar casos de uso – Top-‐down – Boeom-‐up

•  Qual a forma mais adequada? – Enunciado do problema – Organização mental e capacidade de abstracção de cada um

– Consistência na granularidade

© Ana Moreira

Order Processing Problem Statement •  Problem Descrip9on

–  We are developing an order processing soAware for a mail order company called Na9onal Widgets, which is a reseller of products purchased from various suppliers.

–  Twice a year the company publishes a catalog of products, which is mailed to customers and other interested people.

–  Customers or their representa9ves purchase products by submihng a list of products with payment to Na9onal Widgets. Na9onal Widgets fills the order and ships the products to the customer’s address.

–  The order processing soAware will track the order from the 9me it is received un9l the product is shipped.

–  Na9onal Widgets will provide quick service . They should be able to ship a customer’s order by the fastest, most efficient means possible.

–  Customers may return items but will some9mes pay a fee.

•  Assump9ons –  An electronic interface, such as web, would be good for some

customers. –  We expect to use mul9ple shipping companies and insured methods.

6

© Ana Moreira

Atores •  Atores interagem com o sistema; podem ser pessoas, outros sistemas ou disposi9vos de hardware

•  Cada ator deve comunicar com pelo menos 1 caso de uso •  Atores estão fora do sistema (casos de uso estão dentro) e são SEMPRE representados nas fronteiras externas

•  Atores podem relacionar-‐se entre si usando herança •  Perguntas que ajudam a iden9ficar atores:

–  Quem necessita do sistema para poder realizar suas ac9vidades?

–  Quem está interessado nos resultados do sistema? –  Quem é responsável pela administração do sistema? –  Com que outros sistemas o sistema deve comunicar? –  Quem fornece informação ao sistema?

© Ana Moreira

Atores do exemplo •  Customer; Customer Rep

–  a person who orders products from Na9onal Widgets

•  Shipping company –  such as DHL, FedEX

•  Clerk –  an employee of Na9onal Widgets who packages, labels, and ships orders

•  Inventory system –  soAware that tracks the company inventory

•  Accoun9ng system –  soAware that keeps the company books

7

© Ana Moreira

Use cases •  O conjunto, todos os casos de uso descrevem todas as maneiras possíveis de usar o sistema

•  Começando por iden9ficar atores, é mais fácil depois iden9ficar os casos de uso. Cada ator executa um número de casos de uso

•  Um caso de uso representa-‐se graficamente por uma oval e descreve-‐se textualmente em linguagem natural

© Ana Moreira

Iden9ficar casos de uso •  Se possível, entrevistar os u9lizadores do (futuro) sistema

•  Interpretar os requisitos na perspec9va dos atores •  Ajuda a responder às seguintes perguntas:

–  Quais são as tarefas principais de um ator? –  Será que o ator tem que ler, criar ou mudar informação do sistema?

–  Será que o ator tem que informar o sistema sobre alguma mudança externa?

–  Será que o ator recebe alguma informação do sistema? –  Será que o ator quer ser informado sobre mudanças inesperadas?

8

© Ana Moreira

Order Processing Use Cases •  From a customer &customer rep: place order, send catalog, get status on order, return product, cancel order, register complaint

•  To shipping companies: packages ready for delivery •  From clerk: print mailing labels, calculate postage •  To inventory system: give product informaMon, update product quanMMes

•  From inventory system: back-‐ordered items received

•  To accoun9ng system: charge account, credit account

Casos de uso PRECISAM ser descritos, primeiro textualmente e depois mais rigorosamente usando cenários, diagramas de actividade, diagramas de sequência, ...

© Ana Moreira

Modelo de casos de uso

•  Mostra as fronteiras do sistema e capta a funcionalidade que o futuro sistema deve oferecer

•  Pode funcionar como um entregável entre o engenheiro de so/ware e o cliente –  Por isso, é importante que seja legível por não

especialistas em UML

•  É a base para as fases seguintes –  É estruturado pelo modelo de análise

9

© Ana Moreira

Comentários?

© Ana Moreira

Fazer um diagrama de Use Cases (UC) para marcação de consultas médicas

Num sistema de gestão de consultas médicas, um paciente em contacto com um responsável pelo mapa de marcações marca a sua consulta. Eventualmente ela pode ser cancelada por indisponibilidade do paciente. Durante a consulta o médico pode receitar algum medicamento para o paciente. Esta informação deve ser guardada para uma futura consulta. Finalmente o paciente deve pagar a consulta a um empregado do consultório médico, onde obterá um recibo.

10

© Ana Moreira

Model de UCs para Consultas Médicas

Como compara este relativamente ao exemplo anterior?

© Ana Moreira

O que representam os casos de uso?

•  Um caso de uso é composto (definido) por um conjunto de cenários

•  Cada cenário contém uma sequência de passos que descreve uma interacção entre o u9lizador e o sistema

•  Um caso de uso reúne cenários que sa9sfazem um determinado objecMvo do u9lizador

11

© Ana Moreira

Como descrever use cases? •  Descrevendo os seus cenários: em geral um caso de uso tem um cenário principal (ou primário) e vários cenários alterna/vos (ou secundários)

•  Usando descrições semi-‐estruturadas: templates

•  Textualmente

•  Usando técnicas formais: expressões matemá9cas, linguagens algébricas, etc.

•  Usando outros modelos UML: diagramas de ac9vidade e diagramas de sequência

© Ana Moreira

Cenários •  Um cenário é uma sequência de eventos mostrando as interacções upicas e a informação trocada entre um u9lizador e o sistema. – Ocorre durante uma execução par9cular do sistema – Pode ser escrito em linguagem natural – É uma instância específica de um caso de uso

•  Qualquer use case tem sempre 2 9pos de cenários: – Principal (ou primário): descreve a situação quando tudo corre bem (visão op9mista – happy day scenario)

– Secundário (ou alterna9vo): permite uma sequência diferente de eventos em relação ao cenário principal, tratando excepções e casos de erro

12

© Ana Moreira

Template: uma proposta Nome:

Descrição: descrição execu9va

Pré-‐condições: pré-‐requisitos para a execução com sucesso

Pós-‐condições: estado do sistema depois da execução bem

sucedida

Atores: que comunicam com o caso de uso

Cenário principal: passos atómicos do caso de uso

Cenários secundários: desvios do cenário com sucesso

© Ana Moreira

Place Order Use Case Pre-‐condi9on:

A valid user has logged into the system

Flow of Events:

Basic Path: 1.  The use case starts when the

customer selects place order

2.  The customer enters his/her name and address

3.  If the customer enters only the zip code the system will supply the city and the state

4.  The customer will enter product codes for desired products

5.  The system will supply a product descrip9on and the price for each item

6.  The system will keep running total of items ordered as they are entered

7.  The customer will enter credit card payment information

8.  The customer will select submit 9.  The system will verify the

information, save the order as pending, and forward the payment information to the accounting system

10.  When payment is confirmed, the order is marked Confirmed, an order ID is returned to the customer, and the use case ends

Post Condition: The order has been saved in the system and marked Confirmed

13

© Ana Moreira

Place Order Secondary Scenarios •  payment not there

•  order incomplete •  order gets lost •  shipping address is incomplete •  product code does not match actual products

•  product no longer carried •  payment bad •  customer pays by check

•  customer sends order by mail •  customer phones in order

© Ana Moreira

Cenário secundário

•  Cenário secundário “Product code does not match actual products”

–  “Place order” extension points: “Product code does not match actual products”, antes do passo 5

1.  The system shows a message saying that the product code is invalid

2.  Return to step 4 of the main scenario

14

© Ana Moreira

Especificar Alterna9vas (if-‐statement) •  Get Status on Order use case Flow of Events:

1.  The user may enter an order ID, customer ID, or customer name

2.  The user will press find 3.  If the user entered an order ID

a)  The system will display the order

4.  If the user entered a customer name or customer ID a)  The system will return a list of all orders for that

customer

b)  The user will select one order from the list

c)  The system will display the order

© Ana Moreira

Especificar Repe9ções (ciclos) Flow of Events:

Basic Path: 1.  The use case starts when the customer

selects place order 2.  The customer enters his/her name and

address 3.  If the customer enters only the zip

code the system will supply the city and the state


5.   For each product code entered

a)  The system will supply a product descripMon and the price for each item

b)  The system will add the price of the item to the total


7.  The customer will select submit 8.  The system will verify the


9.  When payment is confirmed, the order is marked Confirmed, an order ID is returned to the customer, and the use case end

15

© Ana Moreira

Flow of Events: Basic Path:

1.  The use case starts when the customer selects place order

2.  The customer enters his/her name and address

3.  If the customer enters only the zip code the system will supply the city and the state


5.   While the customer enters product codes

a)  The system will supply a product descrip9on and the price for each item

b)  The system will add the price of the item to the total


7.  The customer will select submit. 8.  The system will verify the


9.  When payment is confirmed, the order is marked Confirmed, an order ID is returned to the customer, and the use case end

Especificar Repe9ções (ciclos)

© Ana Moreira

Relações entre use cases •  “includes”

–  o comportamento de B é incluído em A –  o use case B incluído é necessário para assegurar a

funcionalidade do A –  A conhece a existência de B –  A é o caso de uso base

•  “inherits” –  idên9co à herança entre classes –  A herda o comportamento de B e pode redefini-‐lo ou

estendê-‐lo –  é possível definir use cases abstractos –  B é o super-‐ caso de uso

•  “extends” –  o comportamento de B pode vir a estender o

comportamento de A –  A não conhece a existência de B –  A é o caso de uso base

A B «includes»

A B «extends»

A B «inherits»

16

© Ana Moreira

Associação “includes” •  Para promover a reu9lização, partes idên9cas de casos de uso(base) podem ser extraídas para criar um novo caso de uso

•  Casos de uso (base) são depois relacionados com o novo caso de uso usando a associação <<includes>>

•  O novo caso de uso pode não ter significado por si só

use case 1 (base)

use case 2 (included)

<<includes>>

© Ana Moreira

<<includes>>: exemplo •  E se os clientes 9verem que se registar?

•  Qual a consequência para Place Order?

<<includes>>

Place order

Validate customer

Customer Rep

Customer

Register

17

© Ana Moreira

Cancel Order Use Case 1.  The use case begins when a customer requests

“cancel order” 2.   <<include>> Find Order 3.  If the order status is Confirmed

a)  The order is marked Cancelled b)  The accoun9ng system is no9fied to credit the

customer’s account and the use case ends.

4.  If the order status is Shipped a)  The customer is no9fied of NW’s return policy

Modularização Reutilização (rapidez)

© Ana Moreira

Associação “inherits” •  A associação herda entre atores

–  Abstracto/concreto: um ator concreto define-‐se a par9r de um ator abstracto

•  Vantagens: simplificar os diagramas

Client

Customer Rep Customer

«inherits» «inherits»

Ou será que pode ser Customer?

18

© Ana Moreira

<<inherits>> também entre casos de uso

Validate Client

Verify password Scan retina

© Ana Moreira

Associação “extends” •  A associação estende relaciona como um caso de uso pode ser estender o comportamento de outro.

•  O caso de uso original não precisa de saber sobre a existência das extensões. É construído independentemente.

•  Os casos de uso que estendem outros podem ser vistos como interrupções do original

–  para definir casos de excepção, partes opcionais, alterna9vas

(original)

(extensão1) (extensão2)

«extends» «extends»

19

© Ana Moreira

Alguns cenários secundários podem representar-‐se como extensões: exemplo

•  Fluxo de eventos do cenário secundário Seasonal Sale para o caso de uso Place Order

•  Este cenário está relacionado ao principal através de extension points   “Place order” extension points: “Seasonal sale”, antes do passo 5

(ver diagrama)   São representados nos diagramas de use cases

1.  The system will get the sale discount for the product 2.  The system will display the discount on the order 3.  The system will calculate a discount amount 4.  The system will subtract the discount amount from the

order total

© Ana Moreira

<<includes>>

Client Place order _______________

Seasonal sale before step 5 Seasonal sale

«extends»

Validate Client


«inherits» Customer Rep

Customer

«inherits»

Modelo UCs com os três 9pos de relação

20

© Ana Moreira

Mas, e se Seasonal Sale se relacionasse com <<includes>>?

<<includes>>

Client

Place order Seasonal sale

«includes»

Validate Client


Customer Rep

Customer

«inherits»

E agora? Quais as

consequências?

© Ana Moreira

Place Order Use Case Pre-‐condiMon:

A valid user has logged into the system

Flow of Events: Basic Path:

1.   The use case starts when the customer selects place order.

2.   The customer enters his/her name and address

3.   <<includes>> Validate Client

4.   If the customer enters only the zip code the system will supply the city and the state.

5.   <<includes>> Seasonal sale

6.   The customer will enter product codes for desired products.

7.   The system will supply a product descripMon and the price for each item.

8.  The system will keep running total of items ordered as they are entered.

9.  The customer will enter credit card payment information.

10.  The customer will select submit. 11.  The system will verify the

information, save the order as pending, and forward the payment information to the accounting system.

12.  When payment is confirmed, the order is marked Confirmed, an order ID is returned to the customer, and the use case end.

Post Condition: The order has been saved in the system and marked Confirmed.

Má decisão!!!

21

© Ana Moreira

Para construir um modelo de casos de uso

•  Iden9ficar os atores que interagem com o sistema •  Organizar (hierarquicamente) os atores

•  Para cada ator iden9ficar use cases

•  Para cada use case iden9ficar o cenário principal e os secundários

•  Descrever cada cenário

•  Organizar os use cases u9lizando as relações extends, includes e inherits

•  Se exis9rem, acrescentar os atores receptores de informação

© Ana Moreira

Exemplo: sistema de metro

To use the subway, a client has to own a card that must have been credited with some amount of money. A card is bought and credited in special buying machines available in any subway sta9on. The card owner uses this card in an entering machine to ini9ate her/his trip. When s/he reaches the des9na9on, the card is inserted in an exit machine that debits it with an amount that depends on the distance travelled. If the card has not enough credit the gates will not open. The client can ask for a refund of the amount in the card by giving it back to a buying machine.

22

© Ana Moreira

Iden9ficar e definir atores and casos de uso

•  Casos de uso para client:

  Atores:   Client   ClientCard

  BuyCard

  Casos de uso para ClientCard   EnterSubway

  ExitSubway

  CreditCard

  RefundCard

  É possível definir, para qualquer problema, um ator cuja responsabilidade é manter os dados do sistema

© Ana Moreira

Para um sistema bancário – Gerir cartões – Gerir balcões – Gerir ATMs – Gerir funcionários – Gerir clientes – Gerir contas

Que acha dos seguintes casos de uso?

Para o sistema da via verde – Tratar iden9ficadores – Gerir clientes – Gerir veículos – Gerir portagens

Quais os problemas? Estes são bons ou MAUS casos de uso?

modelo&de&casos&de&uso&(usecases) && (análise&de… ·...

Documents