Use Cases: Descrição de Processos

Objetivos

Identificar e escrever use cases
Diagramar use cases
Constrastar use cases de alto nível e expandidos
Contrastar use cases essenciais e reais

Introdução

Use cases são usados para descrever os processos do domínio de problema
São uma excelente forma de explorar e documentar os requisitos funcionais
Antes de elaborar use cases, pode valer a pena elaborar uma tabela de funções básicas como vimos na seção anterior

Use cases

Um use case é um documento narrativo que descreve uma sequência de eventos feitos por um ator no uso de um sistema para completar um processo de interesse deste ator.
- Use cases são "estórias" ou "casos" no uso de um sistema
- As estórias acabam revelando as funcionalidade desejada do sistema
Em UML, um use case é representado assim:

Exemplo de um Use Case de alto nível: Comprar item

Segue uma breve descrição do processo de comprar um item numa loja quando um TPDV é utilizado

Use case:	Comprar item
Atores:		Cliente, Caixa
Tipo:		primário (a ser explicado logo)
Descrição:	Um cliente chega ao caixa com itens a comprar.
		O caixa registra os itens comprados e recebe pagamento.
		No fim, o cliente sai com os itens comprados.

UML não força o formato exato de um Use Case. A clareza na descrição é o essencial.
Iniciamos acima com um Use Case de alto nível, fornecendo poucos detalhes
- Útil para entender rapidamente os processos principais envolvidos

Exemplo de um Use Case expandido: Comprar item com dinheiro vivo

Ignoramos a questão de dar baixa no inventário aqui

Use case:	Comprar item com dinheiro
Atores:		Cliente (iniciador), Caixa
Propósito:	Capturar uma venda e seu pagamento em dinheiro
Resumo:		Um cliente chega ao caixa com itens a comprar.
		O caixa registra os itens comprados e recebe pagamento.
		No fim, o cliente sai com os itens comprados.
Tipo:		primário e essencial
Referência cruzada: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1
		(pode fazer referência a outros use Cases)

Sequência típica de eventos

Ação do ator	Resposta do sistema
O Use Case inicia quando um cliente chega a um caixa munido de TPDV com itens a comprar
O caixa registra a identificação de cada item Se houver mais itens, o caixa pode informar a quantidade também	Determina o preço do item e adiciona a informação ao total da transação de venda A descrição e preço do item corrente são exibidos
Ao completar a entrada dos itens, o caixa indica este fato ao TPDV	Calcula e apresenta o total da venda
O caixa informa o total da venda ao cliente
O cliente efetua o pagamento com dinheiro, possivelmente maior que o total da venda
O caixa registra a quantidade de dinheiro recebida	Mostra o valor do troco ao cliente Gera um recibo impresso
O caixa deposita o dineiro recebido e extrai o troco a devolver O caixa entrega o troco e o recibo impresso ao cliente	Faz log da venda completada
O cliente sai da loja com os itens comprados

Sequências alternativas:
Linha 2: Entrada de um identificador inválido. Indica erro.
Linha 7: Cliente não tinha dinheiro suficiente. Cancela transação de venda.

Atores

Um ator é uma entidade externa ao sistema que, de alguma forma, participa das estórias relatadas no Use Case
Um ator tipicamente estimula o sistema com eventos de entrada ou recebe algo so sistema
Atores são representados pelo papel que desempenham (e não por nome de pessoa, etc.)
Em UML, o ícone que representa um ator é o seguinte:

6-2.gif (1072 bytes)

Para cada Use Case, um dos atores é o iniciador e outros atores podem ser participantes
Atores correspondem frequentemente a papeis de seres humanos mas, às vezes, outros sistemas ou dispositivos elétricos ou mecânicos podem ser atores

O motivo de usar Use Cases

Para decidir e descrever a funcionalidade de comum acordo com o cliente
Servem de documento básico de referência durante todo o processo sobre o que foi prometido
Serve como base para elaborar os testes funcionais do sistema final
Para poder rastrear requisitos funcionais dentro dos modelos de análise, projeto e implementação
- Sabemos que requisitos causaram o aparecimento de determinadas soluções

Um erro frequente ao criar Use Cases

Iniciantes costumam representar cada etapa, operação ou transação como Use Case separado (exemplo: login como Use Case)
Um Use Case deve representar uma iteração completa e útil para os atores
Use Cases são geralmente processos inteiros, cabo-a-rabo e normalmente envolvem muitas etapas ou transações
- Eles modelam os Business Processes do negócio
Etapas comuns a vários Use Cases podem ser agrupados em Use Cases Abstratos, no sentido de minimizar a duplicação de informação
- Falaremos mais sobre isso em outro capítulo
Exemplos de processo:
- Sacar dinheiro num caixa eletrônico
- Fazer pedido de um produto
- Cadastrar-se num curso numa escola
- Verificar a grafia de um documento num processador de texto
- Atender uma chamada telefônica

Identificação de Use Cases

De forma geral, deve-se verificar a lista de requisitos levantados e usar técnicas de brainstorming
Duas formas comuns:
- Foco nos atores
  - Identificar os atores relacionados com o sistema
  - Para cada ator, identificar os processos que eles iniciam ou dos quais participam
  - Para identificar atores, faça as seguintes perguntas sobre o sistema:
    - Quem vai usar a funcionalidade principal do sistema (atores principais)?
    - Quem vai precisar do suporte do sistema para desempenhar suas tarefas do dia-a-dia?
    - Quem deverá manter e administrar o sistema (atores secundários)?
    - Que dispositivos de hardware o sistema precisa manusear?
    - Com que outros sistemas este interage?
    - Quem ou o que tem interesse nos resultados (valores produzidos) do sistema?

Foco nos eventos
- Identificar os eventos externos aos quais um sistema deve responder
- Relacione os eventos aos atores e Use Cases

Diagramas de Use Case

Em UML, um diagrama de Use Case tem o formato seguinte:

6-3.gif (3321 bytes)

O diagrama identifica e relaciona os Use Cases e os relaciona com os atores
Observe que o diagrama de Use Case determina com precisão o que é o "sistema"

Use Cases Primários, Secundários e Opcionais

Use Cases primários: representam processos importantes e/ou comuns (comprar itens)
Use Cases secundários: representam processos menos importantes ou raros (Pedido de reposição de estoque)
Use Cases opcionais: representam processos que talvez não sejam considerados

Use Cases Essenciais versus Reais

Use Cases essenciais: possui uma descrição breve, muito abstrata, sem detalhes, sem mencionar tecnologias empregadas (poderia incluir uma frase: "cliente se identifica" sem maiores detalhes porque a forma de identificação pode mudar com tempo e com a disponibilidade de tecnologia)
Use Cases reais: muito mais concretos, mencionando tecnologias correntemente usadas ("cliente se identifica passando seu Smart Card no leitor")
- Use Cases essenciais são usados mais cedo no processo (antes do design) e Use Cases podem ser transformados em Use Cases reais durante o design
Durante o processo de desenvolvimento:
- Durante o levantamento de requisitos
  - Crie Use Cases em formato de alto nível
  - Crie um diagrama de Use Cases, indicando os relacionamentos
  - Selecione os Use Cases mais críticos, que deverão influenciar o sistema mais ou que envolvam mais risco e escreva uma versão Expandida Essencial
  - Priorize os Use Cases (próximo capítulo)
- Durante a fase de análise
  - Escreva uma versão Expandida Essencial dos Use Cases sendo atacados na iteração corrente (se já não estiver pronta)
- Durante a fase de projeto
  - Escreva uma versão Expandida Real dos Use Cases sendo atacados na iteração corrente

Estudo de Caso: O sistema TPDV

Identificar o sistema, atores e Use Cases

O sistema será a combinação de hardware (o terminal) e software executando nele
Os atores relevantes e alguns processos que eles iniciam são:

Caixa	Fecha caixa
Cliente	Compra itens Devolve itens
Gerente	Start Up Shut Down
Administrador do sistema	Adiciona novos usuários

Escrever Use Cases em formato de alto nível

Use case:	Comprar item
Atores:		Cliente (iniciador), Caixa
Tipo:		primário
Descrição:	Um cliente chega ao caixa com itens a comprar.
		O caixa registra os itens comprados e recebe pagamento.
		No fim, o cliente sai com os itens comprados.

Use case:	Start Up
Atores:		Gerente
Tipo:		primário
Descrição:	Um gerente liga um TPDV para o preparar para uso pelos Caixas.
		O gerente verifica que a data e horas estão corretas.
		O sistema está pronto para uso pelos Caixas

Elaborar um diagrama de Use Cases

6-8.gif (5301 bytes)

Escrever alguns Use Cases no formato Expandido Essencial

Favor ver livro, seção 6.16.5

Priorizar os Use Cases

Ver próximo capítulo

plan-3 programa anterior próxima