Thursday, February 24, 2011

Um tutorial para escrita de casos de uso

A modelagem de casos de uso lida com a formalização, documentação e comunicação de partes dos requisitos funcionais de sistemas computacionais e de processos de negócio. Contrariamente ao senso comum, a escrita de um modelo de casos de uso não é uma tarefa trivial e requer muita atenção devido a detalhes que não são óbvios para o analista de requisitos iniciante.
Trabalho aqui um exemplo de como escrever e como não escrever casos de uso, composto de erros comuns a analistas iniciantes e um refinamento sucessivo para a correção destes erros e produção um descritivo maduro de casos de uso. O exemplo é composto de 7 passos, refinados incrementalmente em níveis crescentes de maturidade.
Escolhemos como exemplo um processo didático de saque de dinheiro em uma máquina 24 horas, chamada aqui de máquina ATM (Automatic Teller Machine). Neste processo de negócio, podemos identificar um caso de uso de sistemas chamado “Sacar Dinheiro”, ativado por um ator primário chamado Correntista.
A nossa primeira tentativa de descrever este caso de uso segue abaixo:
Caso de Uso - Sacar Dinheiro - Versão 1
Ator Primário: Correntista
Objetivo: Permitir ao correntista de um banco conveniado ao banco ATM realizar o saque de dinheiro em espécie.
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O correntista insere a senha e o valor a ser retirado.
3. O correntista retira o dinheiro da máquina 24 horas.
Embora este processo atinja o fim esperado (dinheiro em espécie na mão do correntista), ele não descreve a interação entre o ator primário e o sistema sob desenho. O objetivo primário de um caso de uso é descrever a interação entre atores e o sistema sob desenho. Em uma metáfora com um jogo de ping-pong, a bola na versào 1 fica o tempo todo em um lado da mesa. Não existe conversação, não existe diálogo e portanto não existe captura dos processos de negócio que devem ser conduzidos pelo sistema.
A nossa segunda tentativa de descrever este caso de uso corrige este problema.
Caso de Uso - Sacar Dinheiro - Versão 2

Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação do cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema valida a senha e o saldo do correntista.
5. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
6. O correntista retira o dinheiro da máquina 24 horas.
A versão 2 é uma clara evolução. Existe um diálogo entre o ator e o sistema sob desenho. Alguns erros, entretanto, ainda persistem. Observemos, por exemplo, o passo (2). Como estamos projetando o sistema da máquina 24 horas, devemos nos lembrar que está fora do escopo (por pura impossibilidade) do nosso sistema realizar validações como por exemplo “Cartão Bloqueado ou Cancelado”. Isso é realizado pelo sistema do banco real (instituição de crédito), que se apresenta então como um ator secundário no contexto do nosso sistema. Isso seria identificado no mundo real através da definição da fronteira ou limite do nosso desenho. O erro aqui, portanto, foi ignorar a existência do ator secundário Banco Instituição de Crédito na descrição. Isso nos leva a terceira versão da nossa descrição.
Caso de Uso - Sacar Dinheiro - Versão 3
Ator Primário: Correntista
Ator Secundário: Instituição de Crédito
Objetivo: Permitir ao correntista de uma instituição de crédito conveniada ao banco ATM realizar o saque de dinheiro em espécie.
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha e o saldo do correntista.
5. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
6. O correntista retira o dinheiro da máquina 24 horas.
A terceira versão captura nos passos 2 e 6 as interações com atores secundários, ausentes na versão 2. Mais uma vez, entretanto, erros ainda existem na descrição. Um caso de uso deve capturar todos os processos de negócio realizados, sem no entanto entrar no mérito de como estes processos serão implementados. Em outras palavras, os casos de uso capturam as interações (O QUÊ), sem se preocupar com a implementação destas interações (COMO). Na versão 3, não capturamos processos básicos de um saque bancário, como por exemplo a validação da existência de dinheiro disponível na dispensadora de dinheiro, as restrições de saques diários, restrições de horários e o débito em conta corrente ao final da operação. Isso nos leva a uma quarta versão da nossa descrição.
Caso de Uso - Sacar Dinheiro - Versão 4

Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.
Embora esta versão 4 seja já razoável, muitos analistas de requisitos terminam o trabalho de escrita de casos de uso neste ponto. Estes analistas se esquecem que a ausência dos fluxos alternativos ou de exceção subestima a complexidades dos sistemas computacionais e gera desvios nos cronogramas de projeto. Portanto, é fundamental identificarmos os pontos de extensão deste fluxo. Não devemos, entretanto, realizar este processo verticalmente, mas primordialmente em amplitude para em um segundo momento realizarmos a escrita de cada ponto de extensão. Isso nos leva a versão 5, agora com os fluxos alternativos/exceção.
Caso de Uso - Sacar Dinheiro - Versão 5

Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.
Pontos de Extensão
Ativado do Passo 2 - Cartão Inválido
Ativado do Passo 2 - Cartão Bloqueado ou Expirado
Ativado do Passo 2 - Cartão Não Suportado pela Máquina 24 horas
Ativado do Passo 4 - Senha Inválida
Ativado do Passo 4 - Saldo Insuficiente
Ativado do Passo 4 - Limite Diário na Instituição de Crédito Ultrapassado
Ativado do Passo 5 - Limite de Saque do Banco 24 horas Ultrapassado
Ativado do Passo 5 - Limite de Saque no Horário Ultrapassado
Ativado em Qualquer Passo - Cancelamento da Operação pelo Correntista
Outros pontos de extensão podem existir, naturalmente. O exemplo procura mostrar o fato que um brainstorming destes fluxos alternativos deve ser feito para que estes pontos de extensão sejam capturados.
Dentro da evolução da descrição, devemos também realizar o detalhamento de cada ponto de extensão. Um exemplo para o fluxo Senha Inválida é colocado abaixo.
Caso de Uso - Sacar Dinheiro - Versão 6

Fluxo Alternativo - Senha Inválida
4a. Se o número de tentativas inválidas for igual a 1:
4a1. O sistema exibe a mensagem “Senha Inválida”.
4a2. O sistema retorna ao passo 3.
4b. Se o número de tentativas inválidas for igual a 2:
4b1 O sistema exibe a mensagem “Senha Inválida - O cartão será retido se três tentativas inválidas forem realizadas”.
4b2 O sistema retorna ao passo 3.
4c. Se o número de tentativas inválidas for igual a 3:
4c1. O sistema retém o cartão
4c2. O sistema exibe a mensagem “Senha Inválida - Cartão Retido. Procure a sua agência bancária para devolução do cartão”.
4c3 O sistema termina a operação.
Este trabalho, como citado, deve ser realizado para cada ponto de extensão da descrição do caso de uso.
Finalmente, devemos lembrar sempre que o modelo de caso de uso captura apenas interações entre os atores primários e o sistema sob desenho. Informações complementares como regras de negócio, interfaces gráficas, desenho detalhado ou persistência não são capturados na descrição. Estas informações podem (e devem complementar) a descrição de um caso de uso, sem entretanto interferir na legiblidade da leitura dos fluxos. A versão 7 (e última) deste artigo mostra como isso poderia ser realizado para regras de negócio simples do nosso exemplo de caso.
Caso de Uso - Sacar Dinheiro - Versão 7 (Final)

Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.
Pontos de Extensão
Fluxo Alternativo - Senha Inválida
4a. Se o número de tentativas inválidas for igual a 1:
4a1. O sistema exibe a mensagem “Senha Inválida”.
4a2. O sistema retorna ao passo 3.
4b. Se o número de tentativas inválidas for igual a 2:
4b1 O sistema exibe a mensagem “Senha Inválida - O cartão será retido se três tentativas inválidas forem realizadas”.
4b2 O sistema retorna ao passo 3.
4c. Se o número de tentativas inválidas for igual a 3:
4c1. O sistema retém o cartão
4c2. O sistema exibe a mensagem “Senha Inválida - Cartão Retido. Procure a sua agência bancária para devolução do cartão”.
4c3 O sistema termina a operação.
… Outros Pontos de Extensão
Regras de Negócio

RN006 - Se correntista não possui cheque especial, verificar se o saldo em conta corrente é maior que o valor a ser sacado.
RN007 - Se correntista possui cheque especial, verificar se o saldo em conta corrente é maior que o valor a ser sacado mais o valor do limite de crédito.
… Outras regras de negócio
O resumo deste pequeno artigo mostra ao leitor que o processo de escrita de casos de uso é complexo e cheio de nuances. Para os interessados, sugerimos o excelente “Escrevendo Casos de Uso - Allistair Cockburn”, que descreve em bastante profundidade como escrever e como não escrever casos de uso.

No comments: