Mudanças entre as edições de "Casos de Uso"

Edição das 12h00min de 15 de agosto de 2007

Introdução

Casos de Uso (conhecidos como "Use Cases" em inglês) são uma ferramenta de desenvolvimento, geralmente utilizada para o desenvolvimento de software, com o intuito de determinar as especificações funcionais de um sistema. Estas podem ser agrupadas em um documento que descreve qual é o o objetivo do "mundo real" relativo ao sistema, quais serão os seus usuários e que funções o sistema deverá permitir ou facilitar que as pessoas realizem.

Por exemplo: a especificação funcional de um caixa automático de banco (conhecidos em inglês como ATMs) deverá indicar que as pessoas que o utilizarão são correntistas daquele banco, e que as funções que elas poderão realizar através daquele sistema serão o depósito, o saque, o pagamento de contas. Nessa especificação, não deverá constar a função "Abrir Conta", pois supomos que um banco não permitirá que uma pessoa crie uma conta bancária a não ser pessoalmente ou por procuração.

No caso do Stoa, que é um sistema em desenvolvimento contínuo, acreditamos que os Casos de Uso podem ser um canal de comunicação entre os usuários e os desenvolvedores, que facilitará a expressão de desejos e necessidades pelos usuários de maneira semi-formal, o que facilitará a compreensão desses desejos e necessidades por parte dos desenvolvedores.

Além disso, os Casos de Uso permitem o desenvolvimento de testes funcionais, na medida em que somente sabendo qual é o funcionamento esperado de um sistema é que podemos determinar um teste para verificar se este funcionamento é realizado ou não.

Outra utilidade dos Casos de Uso é serem eles mesmos um tipo de documentação do sistema, que se não é imediatamente apropriada para uso como documentação para o usuário final, é ao menos útil como esboço para a documentação para o usuário final.

Os Casos de Uso do Stoa devem ser compreendidos dentro de certos limites, ditados pela delimitação do conceito do que é o Stoa, pela indicação de quais são seus "atores" e dos objetivos gerais desses atores. (Entendemos por "ator", aqui, o "tipo de usuário" do sistema - ou seja, do ponto de vista "mecânico" nada mais do que uma série de bits - não queremos de maneira alguma implicar que as pessoas que usam o Stoa estejam "atuando", a menos que façam isso por sua própria vontade).

Definições

O que é o Stoa?

O Stoa é uma rede social dos alunos, professores e funcionários da USP.

Quais são os atores do Stoa?

Alunos, Professores e Funcionários.

Quais são os objetivos de cada tipo de usuário do Stoa?

Alunos: Aprender
Professores: Ensinar, Pesquisar
Funcionários: Facilitar o ensino
Todos: Comunicar-se.

Estas definições não são um caso de uso; elas delimitam os limites dentro dos quais escreveremos os casos de uso, a partir do conceito do que é o Stoa, de quais são seus usuários e o que estes usuários querem ao utilizar o sistema.

Formato de um Caso de Uso

Um Caso de Uso pode ter uma infinidade de formatos, dependendo de como seu autor desejar especifica-lo. As principais diferenças entre um formato e outro são a ausência ou presença de campos de informação. Por exemplo, um autor pode considerar que para o caso de uso "Sacar Dinheiro" não é necessário indicar quais são as precondições para que o ator utilize o caixa automático de banco (possuir conta, estar com o cartão em mãos, etc.); outro autor pode considerar que essa informação é necessária. É possível deixar a escolha do formato a cargo de cada autor individual, mas isso tornaria o conjunto dos casos de uso menos coerente, e portanto menos interessante para os programadores, que irão no final do processo utilizar os casos de uso para escrever o sistema. Portanto, tentaremos adotar um formato comum nos casos de uso do Stoa, que seja ao mesmo tempo suficientemente completo e com o menor número de elementos possível, a fim de que seja útil e simples.

Exemplo de um Caso de Uso

Depositar Cheque

Ator principal: cliente

1. Cliente fornece informações de identificação.

2. Cliente insere envelope com cheque a depositar.

3. Sistema confirma recebimento do envelope e finaliza transação.

Exceções:

1.a. Caso o sistema não possa identificar o cliente, continuar com o caso de uso "Solucionar problema de identificação".

3.a. Caso o sistema não consiga identificar que o cliente inseriu um envelope, ele deve apresentar ao cliente a opção de notificar um funcionário, e opcionalmente oferecer ao cliente a opção de bloquear o caixa até que o funcionário apareça.

Comentários sobre o exemplo

O Caso de Uso "Depositar Cheque" tem a seguinte estrutura:

1. Nome
2. Lista de Atores
3. Sequência de Etapas
4. Exceções.

Tal como referido no item Formato de um Caso de Uso, este caso de uso poderia ter outros itens, como por exemplo Versão, Autor, e alguns outros - veja o formato de caso de uso na página da wikipedia (em inglês) sobre Casos de Uso: http://en.wikipedia.org/wiki/Use_case.

Nome de um Caso de Uso

O nome de um caso de uso deve ser informativo e tão simples quanto possível. Segundo os autores do livro Patterns for Effective Use Cases, o nome de um caso de uso deve ser um VerbPhraseName, ou seja, o nome de um caso de uso deve ser uma frase que corresponde a uma ação, geralmente escrita como um verbo. Bons nomes para casos de uso seriam, no caso do Stoa, 'Escrever mensagem de blog', 'Criar comunidade' ou 'Adicionar contato'.

Lista de Atores de um Caso de Uso

Os Atores de um Caso de Uso são sempre pessoas que utilizam o sistema com um determinado objetivo em mente. Portanto devemos indicar como sendo o Ator de um caso de uso a pessoa que tem um desejo ou uma necessidade, e que pretende satisfazer esse objetivo utilizando o sistema. No caso do Stoa, identificamos três atores (tipos de usuários):

Alunos, Professores e Funcionários

Esta divisão poderia ser refinada; entretanto acreditamos que caso seja necessário escrever casos de uso aplicáveis apenas a categorias mais específicas de um tipo de usuário, será mais adequado criar papéis que subdividam estas categorias em categorias mais específicas. Por exemplo, se for necessário no futuro escrever casos de uso específicos para 'alunos estrangeiros', criaremos o papel Aluno Estrangeiro, e então pdoeremos identificar no caso de uso 'Traduzir texto' o ator como sendo um Aluno Estrangeiro.

Sequência de Etapas

A sequência de etapas deve, de maneira global, corresponder a uma única função ou objetivo do ator primário. Na terminologia dos autores de Patterns for Effective Use Cases, um caso de uso deve contemplar um CompleteSingleGoal (objetivo único e completo em si mesmo), ou seja, a sequência de etapas deve ser uma lista ordenada de passos a serem dados para que o usuário, a partir de uma situação 'padrão' (no caso do Stoa, usuário logado no sistema, com a página principal carregada no navegador), consiga obter um resultado tangível.

O conjunto das etapas deve ser razoavelmente homogêneo, isto é, as etapas não devem ser cada uma de um 'nĩvel de abstração' muito diferente do outro. Por exemplo, um caso de uso não deve ser assim:

1. Usuário decide qual palavra-chave irá pesquisar.
2. Usuário pressiona tecla correspondente à primeira letra da palavra-chave que deseja pesquisar.
3. Usuário repete etapa 2 tantas vezes quantas necessário até escrever toda a palavra-chave.
4. Usuário move o mouse até o botão "Ok".
5. Etc.

No exemplo acima, a primeira etapa (usuário decide palavra-chave) corresponde a uma função que pode ser dita de 'alto nível' de abstração - metaforicamente, um objetivo 'claramente visível'. As etapas seguintes podem ser ditas de 'baixo nível' de abstração - cada uma corresponde a uma etapa a ser realizada pelo usuário, mas de maneira muito diferente da etapa 1. Metaforicamente, as demais etapas são 'microscópicas'.

Exceções

As exceções devem complementar a sequência principal do caso de uso de modo que o conjunto da sequência principal mais as exceções constitua o conjunto de todas as possibilidades funcionais relevantes para o caso.

Entretanto, se as exceções tornam-se muito numerosas ou muito ramificadas, isto é sinal de que possivelmente o caso de uso deve ser fracionado, por exemplo promovendo uma exceção ao status de caso de uso.

Referências

Adolph, Steve & Bramble, Paul. Patterns for Effective Use Cases.

http://en.wikipedia.org/wiki/Use_case

http://alistair.cockburn.us/index.php/Resources_for_writing_use_cases