| Diretriz: Caso de Uso |
 |
 |
|
| Elementos Relacionados |
|---|
ExplicaçãoHá várias palavras-chave nessa definição:
A funcionalidade de um sistema é definida por casos de uso diferentes, onde cada um representa um fluxo de eventos específico. A descrição de um caso de uso define o que ocorre no sistema quando o caso de uso é executado.
Em um caixa eletrônico, o cliente pode, por exemplo, retirar dinheiro de uma conta, transferir dinheiro para uma conta ou verificar o saldo de uma conta. Essas funções correspondem a fluxos que você pode representar com casos de uso. Cada caso de uso tem uma tarefa própria para realizar. Os casos de uso coletados constituem todas as maneiras possíveis de utilizar o sistema. Você pode obter uma idéia de uma tarefa de casos de uso simplesmente observando o seu nome. Como Localizar Casos de UsoSegue, abaixo, um conjunto de perguntas úteis para identificar os casos de uso:
Casos de uso que às vezes são omitidos, uma vez que eles não representam aquelas que geralmente são as funções primárias do sistema, podem ser dos seguintes tipos:
Se você desenvolveu um modelo de casos de uso de negócios e um modelo de análise de negócios, esses artefatos são um bom começo para a identificação dos casos de uso. Como um Caso de Uso SurgeNas iterações iniciais da elaboração, apenas alguns casos de uso (os que são considerados significativos para a arquitetura) são descritos detalhadamente além da breve descrição. Você sempre deve desenvolver primeiro um esquema do caso de uso (no formato passo a passo) antes de se aprofundar nos detalhes. Essa descrição passo a passo deve ser a primeira tentativa de definir a estrutura do fluxo de eventos do caso de uso (consulte Fluxo de Eventos - Estrutura a seguir). Sempre comece com o fluxo básico do caso de uso. Depois que houver algum acordo sobre o esquema do fluxo básico, você pode adicionar o que os fluxos alternativos devem ser em relação ao fluxo básico. Em direção ao fim da elaboração, todos os casos de uso planejados para serem descritos detalhadamente devem ser concluídos. Todos os Casos de Uso São Descritos Detalhadamente?Geralmente, há casos de uso tão simples no modelo que não precisam de uma descrição detalhada do fluxo de eventos, um esquema passo a passo é suficiente. Os critérios para tomar essa decisão são: que você não perceba inconsistência entre os usuários leitores sobre a que o caso de uso se refere e que os designers e os testadores estejam confortáveis com o nível de detalhe fornecido pelo formato passo a passo. Os exemplos são casos de uso que descrevem a entrada simples ou a recuperação de alguns dados do sistema. O Escopo de um Caso de UsoGeralmente, é difícil decidir se um conjunto de interações do usuário do sistema, ou uma caixa de diálogo, é um ou são vários casos de uso. Considere o uso de uma máquina de reciclagem. O cliente insere itens de depósito como, por exemplo, latas, garrafas e caixotes na máquina de reciclagem. Ao inserir todos os itens de depósito, basta pressionar um botão e um recibo é impresso. Esse recibo pode ser trocado por dinheiro. É um caso de uso para inserir um item de depósito e outro caso de uso para solicitar o recibo? Ou trata-se apenas de um caso de uso para os dois? Há duas ações, mas uma sem a outra é de pouco valor para o cliente. Mais exatamente, é o diálogo completo, com todas as inserções e a obtenção do recibo, que tem valor para o cliente (e faz sentido para ele). Portanto, o diálogo completo, desde a inserção do primeiro item de depósito, até o pressionamento do botão e a obtenção do recibo, é um caso de uso completo, um caso de uso. Além disso, você deseja manter as duas ações juntas, para poder verificá-las ao mesmo tempo, modificá-las e testá-las juntas, escrever manuais para elas e gerenciá-las como uma unidade. Esse procedimento torna-se bem óbvio em sistemas maiores. Como os Casos de Uso são RealizadosUm caso de uso descreve o que ocorre no sistema quando um agente interage com o sistema para executar o caso de uso. O caso de uso não define como o sistema executa internamente suas tarefas em termos de objetos de colaboração. Mostrar esse procedimento é tarefa das realizações de casos de uso. Exemplo: No exemplo do telefone, o caso de uso indica, entre outros pontos, que o sistema emite um sinal quando o fone é retirado do gancho e que o sistema recebe os dígitos, encontra a parte receptora, toca o telefone, conecta a chamada, transmite a fala etc. Em um sistema em execução, uma instância de um caso de uso não corresponde a qualquer objeto específico no modelo da implementação (por exemplo, uma instância de uma classe no código). Em vez disso, corresponde a um fluxo específico de eventos que é disparado por um agente e executado como uma seqüência de eventos entre um conjunto de objetos. Em outras palavras, as instâncias de casos de uso correspondem a instâncias de comunicação dos objetos implementados. Esse processo é denominado realização do caso de uso. Geralmente, os mesmos objetos participam das realizações de mais de um caso de uso. Por exemplo, os casos de uso Depósito e Retirada em um sistema bancário podem utilizar um determinado objeto de conta na sua realização. Isso não significa que os dois casos de uso se comunicam, apenas que usam o mesmo objeto na sua realização. Você pode visualizar um fluxo de eventos composto por vários subfluxos, que juntos compõem o fluxo total dos eventos. É possível reutilizar a descrição de um subfluxo em fluxos de eventos de outros casos de uso. Os subfluxos, na descrição de um fluxo de eventos do caso de uso, podem ser comuns aos de outros casos de uso. No design, você deve ter os mesmos objetos com esse comportamento comum para todos os casos de uso relevantes, ou seja, apenas um conjunto de objetos deve ter esse comportamento, independentemente do caso de uso que esteja executando. Exemplo: Em um sistema de caixa eletrônico, o subfluxo inicial é o mesmo no fluxo de eventos dos casos de uso Retirar Dinheiro e Verificar Saldo. O fluxo de eventos dos dois casos de uso começa verificando a identidade do cartão e o código de acesso pessoal do cliente. Um Caso de Uso Tem Muitas Instâncias PossíveisUma instância de casos de uso pode seguir um número de caminhos quase ilimitado, mas enumerável. Esses caminhos representam as opções abertas para a instância de casos de uso na descrição do fluxo de eventos. O caminho escolhido depende dos eventos. Os tipos de eventos incluem:
Exemplo: No caso de uso Reciclar Itens, no Sistema da Máquina de Reciclagem, o Cliente tem sempre duas opções: entregar outro item de depósito ou obter o recibo de itens retornados.
Exemplo: No caso de uso Retirar Dinheiro em um sistema de caixa eletrônico, o fluxo de eventos será diferente, se o Cliente solicitar mais dinheiro do que ele tem na conta. Portanto, a instância de casos de uso seguirá caminhos diferentes. Simultaneidade de Instâncias de Casos de UsoInstâncias de vários casos de uso e várias instâncias do mesmo caso de uso funcionam ao mesmo tempo, se o sistema permitir isso. Na modelagem de casos de uso, você pode assumir que as instâncias de casos de uso podem estar ativas ao mesmo tempo sem conflito. Espera-se que o modelo do design resolva esse problema, porque a modelagem de casos de uso não descreve como eles funcionam. Uma maneira de visualizar isso é assumir que apenas uma instância de casos de uso está ativa no momento e que executar essa instância é uma ação atômica. Na modelagem de casos de uso, a "máquina de interpretação" é considerada infinitamente rápida, de forma que a serialização das instâncias do caso de uso não é um problema. NomeCada caso de uso deve ter um nome que indica o que é alcançado pela interação com o agente. Talvez o nome precise ter várias palavras para ser entendido. Dois casos de uso não podem ter o mesmo nome. Exemplo: Estes são exemplos de variações do nome do caso de uso Reciclar Itens no exemplo da Máquina de Reciclagem:
Descrição RápidaA breve descrição do caso de uso deve refletir sua finalidade. Ao escrever a descrição, faça referência aos agentes envolvidos no caso de uso, ao glossário e, se precisar, defina novos conceitos. Exemplo:Segue, abaixo, amostras de breves descrições dos casos de uso Reciclar Itens e Adicionar Novo Tipo de Garrafa no Sistema da Máquina de Reciclagem: Reciclar Itens: O usuário utiliza essa máquina para contar automaticamente todos os itens retornados (garrafas, latas e caixas) e receber um recibo. O recibo deve ser pago em uma caixa registradora (máquina). Incluir Novo Tipo de Garrafa: Novos tipos de garrafas podem ser incluídos na máquina, iniciando-a no 'modo de aprendizagem' e inserindo 5 amostras, como no retorno de itens. Assim, a máquina pode medir as garrafas e aprender a identificá-las. O gerente especifica o valor do reembolso para o novo tipo de garrafa. Fluxo de Eventos - ConteúdoO Fluxo de Eventos de um caso de uso contém as informações mais importantes derivadas do trabalho de modelagem do caso de uso. Ele deve descrever o fluxo de eventos do caso de uso claramente, para que alguém de fora o entenda facilmente. Lembre-se de que o fluxo de eventos deve apresentar o que o sistema faz, e não como é o design do sistema para realizar o comportamento exigido. As diretrizes para o conteúdo do fluxo de eventos são:
Se você usou determinados termos em outros casos de uso, verifique se usou exatamente os mesmos termos neste caso de uso e se o significado pretendido é o mesmo. Para gerenciar os termos comuns, coloque-os em um glossário.
Fluxo de Eventos - Estrutura
|
|
1.1. Início do Caso de Uso
Este caso de uso começa quando o agente Operador configura o sistema para criar uma ordem de medição. O sistema recuperará todos os agentes Elemento da Rede, seus objetos de medição e as funções de medição correspondentes que estiverem disponíveis para esse Operador específico. Os Elementos de Rede disponíveis são aqueles que estão em operação e os que o Operador tem permissão para acessar. A disponibilidade das funções de medição depende do que foi configurado para um determinado tipo de objeto de medição. 1.2. Configuração da Ordem de Medida O sistema permite que o agente Operador selecione os Elementos da Rede que serão medidos e, em seguida, mostre os objetos de medição que estão disponíveis para os Elementos de Rede selecionados. O sistema permite que o Operador selecione a partir dos objetos de medição e, em seguida, selecione as funções de medição que serão configuradas para cada objeto de medição. O sistema permite que o Operador insira um comentário textual na ordem de medição. O Operador configura o sistema para completar a ordem de medição. O sistema responderá gerando um nome exclusivo para a ordem de medição e configurando os valores padrão para quando, com que freqüência e por quanto tempo a medição deve ser feita. Os valores padrão são exclusivos para cada Operador. O sistema permite, em seguida, que o Operador edite esses valores padrão. 1.3. Inicialização da Ordem O Operador configura o sistema para inicializar a ordem de medição. O sistema registrará a identidade do Operador de criação, a data de criação e o status "Planejado" da ordem de medida. 1.4. Finalização do Caso de Uso O sistema confirma a inicialização da ordem de medição para o Operador, e a ordem de medição fica disponível para que os outros agentes possam ver. |
Descrevendo um caso de uso: Neste estilo, é fácil ler o texto e acompanhar o fluxo de eventos. Tenha este estilo como meta nas suas descrições.
Exemplo 2:
|
Os ordenadores podem criar Ordens para coletar os dados da medição dos Elementos da Rede.
O sistema atribuirá à Ordem um nome exclusivo, bem como valores padrão que indicam o comprimento e o tempo da medição, além da freqüência em que é repetida. O Ordenador poderá editar esses valores. Ele deve especificar mais a função da medição, o elemento de rede e os objetos de medição que se aplicam. O Ordenador também pode adicionar um comentário pessoal à ordem. Quando as informações necessárias foram definidas, uma nova Ordem foi criada e inicializada com os atributos definidos, o nome do criador e a data de criação. O status da ordem será definido como "Planejado". (Os possíveis valores para o status são: Planejada, Em Execução, Concluída, Cancelada e Errada.) A interface do usuário é notificada de que uma nova Ordem foi criada e recebe uma referência para a nova Ordem para que ela possa ser exibida. |
Descrevendo um caso de uso: Este estilo é legível, mas não há um fluxo de eventos claro.
Exemplo 3:
'Administrate order' (User identity)
REPEAT
<='Show administer order menu'
IF (=> 'Creating an Order' (Measurement function,
network element, measurement object)) THEN
The system finds a unique name, default values for when and
how long the measurement should be executed.
<= 'Show order' (Default attributes)
REPEAT
=> 'Edit order' (Attribute to change, New value of attribute)
<= 'Update screen' (New attributes)
UNTIL (All attributes are defined)
REPEAT
IF (=> 'Edit order' (Attribute to change, New value of attribute))
THEN <= 'Update screen' (New attributes)
ELSIF (=> 'Save order' (Order identity, Attributes)) THEN
The order is created and initialized in the system with
the defined attributes, the name of the creator,
date of creation and the status 'scheduled'.
<= 'New order created' (The order)
ENDIF
UNTIL (=> 'Quit')
ENDIF
UNTIL 'Quit administer order'
|
Descrevendo um caso de uso: Aqui, o escritor escolheu um estilo formal utilizando pseudocódigo. Este estilo dificulta a compreensão rápida dos passos do processo, mas pode ser útil, se o fluxo de eventos for difícil de capturar com exatidão.
Fluxo dos Eventos - Exemplo
A descrição completa do fluxo de eventos do caso de uso Administrar Ordem, incluindo os fluxos alternativos, pode ser semelhante a:
1. Fluxo de Eventos Básico
1.1. Início do Caso de Uso
Este caso de uso começa quando o agente Operador configura o sistema para criar uma ordem de medição. O sistema recuperará todos os agentes Elemento da Rede, seus objetos de medição e as funções de medição correspondentes que estiverem disponíveis para esse Operador específico. Os Elementos de Rede disponíveis são aqueles que estão em operação e os que o Operador tem permissão para acessar. A disponibilidade das funções de medição depende do que foi configurado para um determinado tipo de objeto de medição.
1.2. Configuração da Ordem de Medida
O sistema permite que o agente Operador selecione os Elementos da Rede que serão medidos e, em seguida, mostre os objetos de medição que estão disponíveis para os Elementos de Rede selecionados. O sistema permite que o agente Operador selecione a partir desses objetos de medição e, em seguida, selecione as funções de medição a serem configuradas para cada objeto de medição.
O sistema permite que o Operador insira um comentário textual na ordem de medição.
O Operador configura o sistema para completar a ordem de medição. O sistema responderá gerando um nome exclusivo para a ordem de medição e configurando os valores padrão para quando, com que freqüência e por quanto tempo a medição deve ser feita. Os valores padrão são exclusivos para cada Operador. O sistema permite, em seguida, que o Operador edite esses valores padrão.
1.3. Inicialização da Ordem
O Operador configura o sistema para inicializar a ordem de medição. O sistema registrará a identidade do Operador de criação, a data de criação e o status "Planejado" da ordem de medida.
1.4. Finalização do Caso de Uso
O sistema confirma a inicialização da ordem de medição para o Operador, e a ordem de medição fica disponível para que os outros agentes possam ver.
2. Fluxo de Eventos Alternativo
2.1. Nenhum Elemento de Rede Disponível
Se em 1.1, Início do Caso de Uso, nenhum Elemento da Rede estiver disponível para ser medido por esse Operador, o sistema informará ao Operador. O caso de uso está concluído.
2.2. Nenhuma Função de Medida Disponível
Se em 1.2, Configurar Ordem de Medição, nenhuma função de medição estiver disponível para os Elementos da Rede selecionados, o sistema informará ao Operador e permitirá que o Operador selecione outros elementos de Rede.
2.3. Cancelamento da Ordem de Medida
O sistema permitirá que o Operador cancele todas as ações a qualquer momento durante a execução do caso de uso. O sistema voltará ao estado em que estava antes do início do caso de uso, e o caso de uso será concluído.
Requisitos Especiais 
Nos Requisitos Especiais de um caso de uso, você descreve todos os requisitos no caso de uso que não são abordados pelo fluxo de eventos. Esses requisitos não funcionais influenciarão o modelo do design. Consulte também a discussão nos requisitos não-funcionais em Diretriz do Produto de Trabalho: Modelo de Caso de Uso. Você pode organizar esses requisitos em categorias como Usabilidade, Confiabilidade, Desempenho e Capacidade de Substituição, mas geralmente há tão poucos deles que esses agrupamentos não são particularmente úteis.
Exemplo:
No Sistema da Máquina de Reciclagem, um requisito especial do caso de uso Devolver Itens de Depósito poderia ser:
A máquina deve ser capaz de reconhecer os itens de depósito com uma confiabilidade de mais de 95%.
Pre-condições e Pós-condições
Pode ser útil utilizar a noção de precondição e pós-condição para esclarecer como o fluxo de eventos inicia e termina. Entretanto, só use isso se for agregar valor ao público do caso de uso.
Uma precondição é o estado do sistema e da sua vizinhança, que é exigido antes do início do caso de uso. Uma pós-condição é o estado que o sistema pode apresentar após o término do caso de uso.
Considere o seguinte:
- Os estados descritos pelas precondições e pós-condições devem ser estados que o usuário pode observar. "O usuário efetuou logon no sistema" ou "O usuário abriu o documento" são exemplos de estados observáveis.
- Uma precondição é uma restrição sobre quando um caso de uso pode começar. Não é o evento que inicia o caso de uso.
- A precondição de um caso de uso não é apenas para um subfluxo, apesar de ser possível definir precondições e pós-condições no nível do subfluxo.
- A pós-condição de um caso de uso deve ser verdadeira independentemente dos fluxos alternativos que foram executados; não deve ser verdadeira apenas para o fluxo principal. Se houver possibilidade de falha, isso será coberto na pós-condição, informando "A ação está concluída ou, se algo tiver falhado, a ação não foi executada", em vez de apenas "A ação está concluída".
- Quando você usa pós-condições junto com os relacionamentos de extensão, deve tomar cuidado para que o caso de uso estendido não introduza um subfluxo que viole a pós-condição no caso de uso base.
- As pós-condições podem ser uma ferramenta poderosa para descrever casos de uso. Você define primeiro o que o caso de uso pretende alcançar - a pós-condição. Em seguida, descreve como alcançar essa condição - o fluxo de eventos necessário.
Exemplo:
Uma precondição para o caso de uso Retirada de Dinheiro no caixa eletrônico: O cliente tem um cartão distribuído pessoalmente que se ajusta na leitora de cartões, recebeu um número PIN e está registrado com o sistema bancário.
Uma pós-condição para o caso de uso Retirada de Dinheiro no caixa eletrônico: No fim do caso de uso, todos os logs de conta e de transação são compensados, a comunicação com o sistema bancário é reinicializada e o cliente recebe o cartão de volta.
Pontos de Extensão
Um ponto de extensão abre o caso de uso para a possibilidade de uma extensão. Ele tem um nome e uma lista de referências para um ou mais locais no fluxo de eventos do caso de uso. Um ponto de extensão pode fazer referência a um único local entre dois passos do comportamento no caso de uso. Também pode fazer referência a um conjunto de locais diferentes.
Utilizar os pontos de extensão com nome ajuda a separar a especificação do comportamento do caso de uso estendido dos detalhes internos do caso de uso base. O caso de uso base pode ser modificado ou reorganizado, contanto que os nomes dos pontos de extensão permaneçam os mesmos e isso não afete o caso de uso estendido. Ao mesmo tempo, você não está carregando o texto que descreve o fluxo de eventos do caso de uso base com os detalhes do local em que o comportamento pode ser estendido. Consulte também Diretriz do Produto de Trabalho: Relacionamento de Extensão.
Exemplo:
Em um sistema telefônico, o caso de uso Fazer Chamada pode ser estendido pelo caso de uso Mostrar Identidade do Chamador. Esse é um serviço opcional, referido muitas vezes como "ID do Chamador", que pode ou não ter sido solicitado pela parte receptora. Uma descrição do ponto de extensão no caso de uso Fazer Chamada pode ser semelhante a:
Nome: Mostrar Identidade
Local: Após a seção 1.9 Tocar Telefone da Parte Receptora.
Diagramas de Casos de Uso
Você pode optar por ilustrar como um caso de uso se relaciona com os agentes e com outros casos de uso em um diagrama de casos de uso (raramente, em mais de um diagrama) pertencente ao caso de uso. Esse procedimento é útil se o caso de uso estiver envolvido com muitos agentes ou se tiver relacionamentos com muitos outros casos de uso. Um diagrama desse tipo é de caráter "local", já que mostra o modelo de casos de uso da perspectiva de um caso de uso apenas e não pretende explicar qualquer fato geral sobre o modelo de casos de uso como um todo. Consulte também Diretriz do Produto de Trabalho: Diagrama de Casos de Uso.
© Copyright IBM Corp. 1987, 2006. Todos os Direitos Reservados. |