Finalidade
  • Descrever um ou mais dos fluxos de eventos do caso de uso em detalhes suficientes para permitir que o desenvolvimento do software seja iniciado nele.
  • Descrever a especificação do caso de uso para a compreensão e satisfação do ator representante ou cliente.
Função:  Especificador de Requisitos  
Freqüência: Uma vez por iteração para cada caso de uso ou fluxo de caso de uso que estiver sendo detalhado na iteração 
Etapas
Informações Adicionais: 
Artefatos de Entrada:    Artefatos Resultantes:   
Mentores de Ferramentas:   

Detalhes de Detalhamento do Fluxo de Trabalho::   

Revisar e Aperfeiçoar os Cenários Para o início da página

Inicie pela revisão e aperfeiçoamento dos cenários com os quais você estará trabalhando no ciclo de desenvolvimento. É possível que eles já tenham sido identificados inicialmente em Atividade: Localizar Atores e Casos de Uso. Utilize esses cenários enumerados como um ponto de partida na determinação do escopo de quais fluxos precisarão ser descritos.

Esboços seqüenciais ajudarão a compreender e a detalhar os fluxos de casos de uso. Outra entrada a ser considerada é o protótipo da interface com o usuário, se já houver algum desenvolvido.

Detalhar o Fluxo de Eventos Para o início da página

Você já deverá ter uma descrição do fluxo de eventos do caso de uso resumida passo a passo. Também é possível criá-lo em Atividade: Localizar Atores e Casos de Uso. Utilize essa descrição passo a passo como ponto de partida e detalhe-a gradualmente.

Descreva os casos de uso de acordo com os padrões decididos para o projeto . 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 iniciar 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. A descrição deve ser uma estrutura com vários parágrafos, nos quais cada um expresse uma ação no formato: "Quando o ator ..., o sistema ...." Também é possível enfatizar a interação escrevendo que o caso de uso envie e receba sinais dos atores, por exemplo: "O caso de uso será iniciado ao receber o sinal 'iniciar' do Operador."
  • Como o caso de uso troca dados com os atores? Se desejar, é possível consultar os argumentos dos sinais, no entanto, seria melhor escrever, por exemplo, "O caso de uso inicia quando o Usuário efetua login no sistema, fornecendo seu nome e sua senha."
  • Como o caso de uso repete o mesmo comportamento? Tente expressar essa questão utilizando uma linguagem simples. No entanto, em casos excepcionais, pode ser vantajoso utilizar construções semelhantes às de código, como "WHILE-END WHILE," "IF-THEN-ELSE" e "LOOP-END LOOP," se for difícil expressar-se com termos correspondentes em linguagem simples. Contudo, em geral, evite utilizar 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. Isso deve ser escrito da mesma maneira. Por exemplo:

    "O ator escolhe uma das opções a seguir, uma ou mais vezes:

    a) . . .

    b) . . .

    c) . . ." etc.

  • 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 poderá iniciar quando a função 'Administrar Ordem' 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 uma nova ordem, o usuário ativa a função 'Nova' e, em seguida, especifica os seguintes dados obrigatórios relacionados à ordem: nome, elementos de rede (pelo menos um) e o tipo de função de medida. Também é possível especificar dados opcionais sobre a ordem: um comentário (uma pequena descrição textual). O usuário ativa então a função 'OK' e uma nova ordem é criada no sistema."

Nota: 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 uma ordem existente e especifica um número para a ordem (inteiro pequeno). Em seguida, o sistema inicializa um formulário com o nome da ordem, seus elementos de rede e o tipo de função de medida. Esses dados são recuperados de 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.

A seguir, outros "itens" a serem considerados na descrição de um caso 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.
  • Utilize os termos do glossário comum e considere as seguintes questões ao redigir o texto:
  • Utilize vocabulário claro e direto. Não use termos complexos quando um termo simples pode ser utilizado.
  • Crie frases curtas e concisas.
  • Evite advérbios, como muito, mais, bastante e outros semelhantes.
  • Utilize a pontuação correta.
  • Evite frases compostas.

Para obter informações adicionais, consulte Diretrizes: Caso de Uso, as discussões sobre conteúdo e o estilo do fluxo de eventos.

Estruturar o Fluxo de Eventos Para o início da página

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 ordem' for requerida 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. No entanto, 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 Caso de Uso.

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

Ilustrar Relacionamentos com Atores e Outros Casos de Uso Para o início da página

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 informações adicionais, consulte Diretrizes: Diagrama de Casos de Uso.

Descrever os Requisitos Especiais Para o início da página

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 informações adicionais, consulte Diretrizes: Caso de Uso, requisitos especiais.

Definir o(s) Protocolo(s) de Comunicação Para o início da página

Defina o protocolo de comunicação a ser utilizado para qualquer ator que seja outro sistema ou hardware externo. Se algum protocolo existente (protocolos particularmente reconhecidos ou protocolos considerados padrão) for utilizado, a descrição do caso de uso deverá nomear o protocolo apenas. Se o protocolo for novo, aponte para onde sua definição possa ser localizada, uma vez que precisará ser totalmente descrita durante o desenvolvimento do modelo de objetos.

Descrever Precondições Para o início da página

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 utilizadas 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 resultante  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 anterior ou em Atividade: Estruturar o Modelo de Caso de Uso.

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

Descrever Pós-condições Para o início da página

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 caixa eletrônico sempre exibir a mensagem 'Bem-vindo' no fim de um caso de uso, isso deve ser documentado na pós-condição do caso de uso.

De forma semelhante, se o caixa eletrônico fechar a transação do cliente no fim de um caso de uso como Realizar 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 utilizadas 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 utilizadas 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 combinado 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 anterior ou em Atividade: Estruturar o Modelo de Caso de Uso.

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

Descrever os Pontos de Extensão Para o início da página

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

Avaliar os Resultados Para o início da página

Analise e discuta o caso de uso com os investidores 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.



Rational Unified Process   2003.06.15