Atividade:  Detalhar um Caso de Uso

Detalhar o Fluxo de Eventos do Caso de Uso

Você já deverá ter uma descrição resumida e passo a passo do fluxo de eventos do caso de uso. Ela é criada em Atividade: Localizar Atores e Casos de Uso. Use essa descrição passo a passo como ponto de partida e detalhe-a gradativamente.

Descreva os casos de uso de acordo com os padrões estabelecidos para o projeto (documentados em Artefato: Guia de Modelagem de Casos de Uso). Decida sobre as seguintes questões antes de descrever os casos de uso para manter a consistência em todos os casos de uso:

• Como o caso de uso começa? O início do caso de uso deve descrever claramente o que o ativa. Escreva, por exemplo, "O caso de uso pode começar quando ... ocorrer."
• Como o caso de uso termina? Informe claramente o que acontece durante o fluxo para o encerramento do caso de uso. Escreva, por exemplo, "Quando ... ocorrer, o caso de uso terminará."
• Como o caso de uso interage com os atores? Para minimizar o risco de mal-entendidos, defina exatamente o que será inserido no interior do sistema e o que será externo. Estruture a descrição em uma série de parágrafos, em que cada um expressa uma ação no formato: "Quando o ator fizer ..., o sistema fará ...." Você também pode enfatizar a interação escrevendo que o caso de uso envia e recebe sinais de atores, por exemplo: "O caso de uso começa quando recebe o sinal de partida do Operador."
• Como o caso de uso troca dados com os atores? Se quiser, você poderá fazer referência aos argumentos dos sinais. No entanto, talvez seja preferível escrever, por exemplo, "O caso de uso começa quando o Usuário fornece seu nome e sua senha para fazer logon no sistema."
• Como o caso de uso repete o mesmo comportamento? Tente expressar essa questão usando uma linguagem simples. Entretanto, em casos excepcionais, pode ser vantajoso usar construções semelhantes às de código, como "WHILE-END WHILE," "IF-THEN-ELSE," e "LOOP-END LOOP," se for difícil se expressar com termos correspondentes em linguagem simples. Contudo, em geral, evite usar construções do tipo de código em descrições de caso de uso, pois elas são difíceis de ler e manter.
• Há alguma situação excepcional em um fluxo de eventos de caso de uso? Algumas vezes, um ator recebe várias opções. Os membros da equipe devem descrevê-las da mesma maneira. Por exemplo:

"O ator seleciona uma das seguintes opções uma vez ou mais:

a) . . .

b) . . .

c) . . ."

• Como o caso de uso deve ser descrito para que o cliente e os usuários possam compreendê-lo? A utilização de uma terminologia específica da metodologia, como caso de uso, ator e sinal, pode dificultar o entendimento do texto desnecessariamente. Para facilitar a leitura do texto, você pode enumerar as ações ou adotar alguma outra estratégia. Seja lá qual for a estratégia adotada, seja específico em relação às diretrizes gerais de modelagem de caso de uso para tê-las em mente durante toda a atividade de descrição de casos de uso.

Concentre-se na descrição do que é feito no caso de uso, e não em como problemas específicos e internos do sistema devem ser solucionados. Ao trabalhar com modelos de objetos, você poderá complementar a descrição com detalhes sobre o funcionamento dos elementos. Portanto, este não é o momento de detalhar a descrição excessivamente. Descreva somente o que você achar que se manterá estável posteriormente.

Se um fluxo de eventos do caso de uso ficar muito abrangente ou complexo, ou se ele parecer conter partes independentes entre si, divida-o em dois ou mais casos de uso.

Consulte o glossário quando redigir o texto descritivo. À medida que novos termos surgem a partir de novos conceitos, inclua-os no glossário. Não altere a definição de um termo sem informar os membros do projeto apropriados.

O Conteúdo da Descrição de um Fluxo de Eventos

A descrição de um fluxo de eventos inclui:

• Como e quando o caso de uso começa.

Exemplo:

"O caso de uso pode começar quando a função 'Administrar Pedido' for ativada por um usuário."

• Quando o caso de uso interage com os atores e quais são os dados trocados entre os dois.

Exemplo:

"Para criar um novo pedido, o usuário ativa a função 'Novo' e especifica os seguintes dados obrigatórios sobre o pedido: nome, elementos da rede (pelo menos um) e tipo de função de métricas. Também podem ser especificados dados opcionais sobre o pedido: um comentário (uma pequena descrição textual). O usuário ativa a função 'Ok' e um novo pedido é criado no sistema."

Observação: Seja explícito quanto aos dados trocados entre os atores e o caso de uso. Caso contrário, o cliente e os usuários provavelmente não entenderão a descrição do caso de uso.

• Como e quando o caso de uso utiliza ou armazena os dados do sistema.

Exemplo:

"O usuário ativa a função 'Modificar' para modificar um pedido existente e especificar um número para o pedido (pequeno número inteiro). Em seguida, o sistema inicializa um formulário com o nome do pedido, seus elementos de rede e o tipo de função de métricas. Esses dados são recuperados em um dispositivo de armazenamento secundário."

• Como e quando o caso de uso termina.

Exemplo:

"O caso de uso termina quando a função 'Sair' é ativada pelo Solicitante."

Descreva também fluxos de eventos incomuns ou excepcionais. Um fluxo excepcional é um subfluxo do caso de uso que não é compatível com o comportamento normal ou básico do caso de uso. Contudo, esse fluxo pode ser necessário em uma descrição completa do comportamento do caso de uso. O primeiro exemplo é o caso típico de um fluxo excepcional. Se o caso de uso receber dados inesperados (o ator não é aquele esperado para o contexto específico), ele será encerrado. A utilização do ator incorreto e o encerramento prematuro não fazem parte do fluxo de eventos normal.

Outros itens a serem considerados na descrição de casos de uso:

• Descreva o fluxo de eventos, não apenas a sua funcionalidade ou finalidade.
• Descreva apenas os fluxos que pertencem ao caso de uso, e não o que ocorre em outros casos de uso utilizados paralelamente a esse.
• Não mencione os atores que não se comunicam com o caso de uso em questão.
• Não insira excesso de detalhes ao descrever a interação do caso de uso com os atores.
• Se não for preciso estabelecer uma ordem dos subfluxos descritos para o caso de uso, não o descreva como se fosse preciso estabelecê-la.
• Use os termos do glossário comum e considere as seguintes questões ao redigir o texto:
• Use vocabulário claro e direto. Não use termos complexos quando um termo simples pode ser usado.
• Crie frases curtas e concisas.
• Evite advérbios, como muito, mais, bastante e outros semelhantes.
• Use a pontuação correta.
• Evite frases compostas.

Para obter mais informações, consulte Diretrizes: Caso de Uso, o tópico sobre conteúdo e estilo do fluxo de eventos.

Estruturar o Fluxo de Eventos do Caso de Uso

O fluxo de eventos de um caso de uso pode ser dividido em vários subfluxos. Quando o caso de uso é ativado, os subfluxos podem ser combinados de várias maneiras, desde que as seguintes questões sejam verdadeiras:

• O caso de uso pode prosseguir a partir de um dos diversos caminhos possíveis, dependendo das informações fornecidas por determinado ator ou dos valores de algum atributo ou objeto. Por exemplo, um ator pode escolher, entre várias opções, o que fará em seguida, ou o fluxo de eventos poderá diferir caso um valor seja inferior ou superior a determinado valor estabelecido.

Exemplo:

Parte da descrição do caso de uso Realizar Saque em um sistema automatizado de caixa eletrônico pode ser "O valor que o cliente deseja sacar é comparado ao saldo da conta. Se o valor ultrapassar o saldo, o cliente será informado e o caso de uso será encerrado. Caso contrário, o dinheiro será retirado da conta."

• O caso de uso pode executar alguns subfluxos em seqüências opcionais.
• O caso de uso pode executar vários subfluxos ao mesmo tempo.

Descreva todos esses fluxos opcionais ou alternativos. Recomenda-se descrever cada subfluxo em um suplemento separado da seção Fluxo de Eventos. Esse procedimento é obrigatório nos seguintes casos:

• Subfluxos que ocupam um grande segmento de determinado fluxo de eventos.
• Fluxos de eventos excepcionais. Dessa forma, o fluxo de eventos básico do caso de uso de negócios ficará melhor destacado.
• Qualquer subfluxo que possa ser executado em vários intervalos do mesmo fluxo de eventos.

Se um subfluxo envolver somente uma pequena parte do fluxo de eventos completo, será melhor descrevê-lo no corpo do texto.

Exemplo:

"Este caso de uso será ativado quando a função 'administrar pedido' for acionada pelos atores Solicitante ou Administrador do Gerenciador de Desempenho. Se o sinal não for originado por um desses atores, o caso de uso encerrará a operação e exibirá a mensagem adequada ao usuário. Entretanto, se o ator for reconhecido, o caso de uso prosseguirá com....."

É possível ilustrar a estrutura do fluxo de eventos com um diagrama de atividades. Consulte Diretrizes: Diagrama de Atividades no Modelo de Casos de Uso.

Para obter mais informações, consulte Diretrizes: Caso de Uso, sobre a estrutura do fluxo de eventos.

Ilustrar Relacionamentos com Atores e Outros Casos de Uso

Crie diagramas de casos de uso que mostrem o caso de uso e seus relacionamentos com os atores e outros casos de uso. Um diagrama desse tipo pode funcionar como um diagrama local do caso de uso, e deve estar relacionado com ele. Lembre-se de que esse tipo de diagrama de caso de uso local é pouco útil, a menos que o caso de uso tenha relacionamentos de extensão ou de inclusão que precisem ser explicados, ou se houver alguma complexidade incomum entre os atores envolvidos.

Para obter mais informações, consulte Diretrizes: Diagrama de Casos de Uso.

Descrever os Requisitos Especiais do Caso de Uso

Qualquer requisito que possa estar relacionado ao caso de uso de negócios, mas que não seja considerado no Fluxo de Eventos, deverá ser descrito nos Requisitos Especiais do caso de uso. Provavelmente, esses requisitos serão não-funcionais.

Para obter mais informações, consulte Diretrizes: Caso de Uso, requisitos especiais.

Descrever Protocolos de Comunicação

Desenvolva um protocolo de comunicação se o ator estiver em outro sistema ou em um hardware externo. A descrição do caso de uso deve informar se algum protocolo (pode ser um protocolo padronizado) será usado. Se o protocolo for novo, descreva-o totalmente durante o desenvolvimento do modelo de objetos.

Descrever Precondições do Caso de Uso

Uma precondição de um caso de uso explica o estado do sistema para que o caso de uso possa começar.

Exemplo:

Para que um sistema de caixa eletrônico possa liberar dinheiro, as seguintes precondições devem ser atendidas:

• A rede do sistema de caixa eletrônico deve poder ser acessada.
• O sistema de caixa eletrônico deve estar pronto para aceitar transações.
• O sistema de caixa eletrônico deve ter pelo menos algum dinheiro disponível para que possa liberar.
• O sistema de caixa eletrônico deve ter papel o suficiente para imprimir um recibo para ao menos uma transação.

Todas essas precondições devem ser válidas para a utilização do caso de uso Liberar Dinheiro.

Cuidado ao descrever o estado do sistema. Evite descrições detalhadas de outras atividades incidentais que possam ocorrer antes desse caso de uso.

As precondições não são usadas para criar uma seqüência de casos de uso. Você nunca precisará executar primeiro um caso de uso e outro em seguida para obter um fluxo de eventos expressivo. Se você achar necessário fazer isso, é provável que tenha decomposto o modelo de casos de uso excessivamente. Corrija esse problema combinando os casos de uso seqüencialmente dependentes em um único caso de uso. Se com isso o   caso de uso ficar muito complexo, considere as técnicas de estruturação de casos de uso apresentadas em Estruturar o Fluxo de Eventos do Caso de Uso acima ou em Atividade: Estruturar o Modelo de Casos de Uso.

Para obter mais informações, consulte Diretrizes: Caso de Uso, Precondições e Pós-condições.

Descrever Pós-condições do Caso de Uso

Uma pós-condição de um caso de uso lista os possíveis estados do sistema no fim do caso de uso. O sistema deve estar em um desses estados no fim da execução do caso de uso. Também é importante informar ações que o sistema executa no fim do caso de uso, independentemente do que tenha ocorrido no caso de uso.

Exemplo:

Se o sistema de caixa eletrônico sempre exibe uma mensagem de boas vindas no fim de um caso de uso, esse item deve ser documentado na pós-condição do caso de uso.

Da mesma forma, se o sistema de caixa eletrônico fechar a transação do cliente no fim de um caso de uso como Efetuar Saque, independentemente do curso de eventos seguido, esse fato deverá ser registrado como uma pós-condição do caso de uso.

As pós-condições são usadas para reduzir a complexidade e melhorar a compreensão do fluxo de eventos do caso de uso.

Em nenhuma circunstância, as pós-condições devem ser usadas para criar uma seqüência de casos de uso. Você nunca precisará executar primeiro um caso de uso e outro em seguida para obter um fluxo de eventos expressivo. Se você achar que isso é preciso, os casos de uso seqüencialmente dependentes deverão ser combinados em um único caso de uso. Se com isso o   caso de uso composto ficar muito complexo, considere as técnicas de estruturação de casos de uso apresentadas em Estruturar o Fluxo de Eventos do Caso de Uso acima ou em Atividade: Estruturar o Modelo de Casos de Uso.

Para obter mais informações, consulte Diretrizes: Caso de Uso, Precondições e Pós-condições.

Descrever Pontos de Extensão

Se o caso de uso tiver que ser expandido por outro caso de uso (consulte Diretrizes: Relacionamento de Extensão), será preciso descrever quais são os pontos de extensão (consulte Diretrizes: Caso de Uso, pontos de extensão).

Avaliar os Resultados

Analise e discuta o caso de uso com os envolvidos para que eles tenham uma boa compreensão do caso de uso e concordem com sua descrição.

A descrição do caso de uso só está completa quando ele descreve tudo o que o caso de uso realiza, implementa ou, de alguma forma, permite do início ao fim. Antes de terminar, verifique se o caso de uso exibe as propriedades que o caracterizam como um "bom" caso de uso. Consulte os pontos de verificação para casos de uso e relatórios de casos de uso em Atividade: Revisar Requisitos.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process