Explicação

Um modelo de casos de uso é um modelo das funções pretendidas do sistema e suas vizinhanças, que serve como contrato entre o cliente e os desenvolvedores. Os casos de uso funcionam como um thread de unificação por todo o desenvolvimento do sistema. O mesmo modelo de casos de uso é o resultado da disciplina Requisitos e é usado como entrada para as disciplinas Análise, & Design e Teste.

O diagrama abaixo mostra uma parte de um modelo de casos de uso para o Sistema da Máquina de Reciclagem.

Um diagrama de casos de uso mostrando um exemplo de um modelo de casos de uso com atores e casos de uso.

Há muitas maneiras de modelar um sistema, cada uma pode atender a uma finalidade diferente. Entretanto, a finalidade mais importante de um modelo de casos de uso é comunicar o comportamento do sistema ao cliente ou ao usuário. Conseqüentemente, o modelo deve ser fácil de entender.

Os usuários e qualquer outro sistema que podem interagir com o sistema são os atores. Como eles representam os usuários do sistema, os atores ajudam a delimitar o sistema e a fornecer uma imagem mais clara do que se espera que seja feito. Os casos de uso são desenvolvidos com base nas necessidades dos atores. Isso garante que o sistema será o que os usuários esperam.

Como Surge o Modelo de Casos de Uso

Os atores e os casos de uso são encontrados utilizando os requisitos dos clientes e dos possíveis usuários como informações vitais. Conforme eles são revelados, os casos de uso e os atores devem ser descritos brevemente. Antes de descrever os casos de uso detalhadamente, o modelo de casos de uso deve ser revisto pelo cliente para verificar se todos os casos de uso e os atores foram encontrados e se juntos eles podem fornecer o que o cliente deseja.

Em um ambiente de desenvolvimento iterativo, você seleciona um subconjunto de casos de uso para ser detalhado em cada iteração. Consulte também Tarefa: Priorizar Casos de Uso.

Quando os atores e os casos de uso forem encontrados, o fluxo de eventos de cada caso de uso será descrito detalhadamente. Essas descrições mostram como o sistema interage com os atores e o que o sistema executa em cada caso individual.

Finalmente, o modelo de casos de uso completo (incluindo as descrições de caso de uso) é revisto, e os desenvolvedores e clientes o usam para concordar sobre o que o sistema deve executar.

Evitando Decomposição Funcional

Não é raro que o modelo de casos de uso se torne uma decomposição funcional do sistema. Para evitar isso, observe os seguintes sintomas:

• Casos de uso "pequenos", significando que a descrição do fluxo de eventos é apenas uma ou poucas frases.
• "Muitos" casos de uso, significando que o número de casos de uso é algum múltiplo de cem, em vez de um múltiplo de dez.
• Os nomes dos casos de uso que são construções como "executar esta operação com esses dados específicos" ou "executar esta função com esses dados específicos". Por exemplo, "Digitar o Número de Identificação Pessoal em um caixa eletrônico" não deve ser modelado como um caso de uso separado para o caixa eletrônico, já que ninguém usaria o sistema para executar apenas isso. Um caso de uso é um fluxo completo de eventos que resulta em algo de valor para um agente.

Para evitar a decomposição funcional, você deve ter certeza de que o modelo de casos de uso ajuda a responder perguntas como:

• Qual é o contexto do sistema?
• Por que o sistema foi criado?
• O que o usuário deseja realizar quando usa o sistema?
• Que valor o sistema agrega aos usuários?

Requisitos Não Funcionais

É muito fácil perceber que os casos de uso são uma forma muito boa de capturar os requisitos funcionais em um sistema. E os requisitos não funcionais? O que são eles e onde são capturados?

Os requisitos não funcionais freqüentemente são categorizados como requisitos de utilização, confiabilidade, desempenho e substituição (consulte também Conceito: Requisito). Geralmente, eles são requisitos que especificam a necessidade de concordância com qualquer requisito legal e regulamentador. Eles também podem ser restrições do design devido ao sistema operacional utilizado, ao ambiente da plataforma, a questões de compatibilidade ou qualquer padrão do aplicativo que se aplique. Em geral, você pode dizer que qualquer requisito que não permita mais de uma opção de design deve ser considerado como uma restrição de design.

Muitos requisitos não funcionais aplicam-se a um caso de uso individual e são capturados dentro das propriedades desse caso de uso. Nesse caso, eles são capturados dentro do fluxo de eventos do caso de uso ou como um requisito especial do caso de uso (consulte a Diretriz: Caso de Uso).

Exemplo:

No Sistema da Máquina de Reciclagem, um requisito não funcional específico para o caso de uso Devolver Itens do Depósito pode ser:

A máquina deve ser capaz de reconhecer os itens de depósito com uma confiabilidade de mais de 95%.

Freqüentemente, os requisitos não funcionais aplicam-se ao sistema inteiro. Esses requisitos são capturados nas Especificações Suplementares (consulte Produto de Trabalho: Especificações Suplementares).

Exemplo:

No Sistema da Máquina de Reciclagem, um requisito não funcional que se aplica ao sistema inteiro pode ser:

A máquina só permitirá um usuário por vez.

O Dilema O Que versus Como

Um das coisas mais difíceis é aprender a determinar em que nível de detalhe os casos de uso devem "iniciar e terminar". Onde os recursos iniciam e os casos de uso começam e onde os casos de uso terminam e o design começa? Sempre dizemos que os casos de uso ou os requisitos de software devem indicar "o que" o sistema executa, mas não "como" ele executa. Considere o seguinte gráfico:

O destino de uma pessoa é o ponto inicial de outra.

Dependendo da sua experiência, você utilizará um contexto diferente para decidir o que acha que é "o que" e o que é "como". Isso deve ser considerado ao determinar se um detalhe específico deve ou não ser excluído do modelo de casos de uso.

Há uma distinção entre casos de uso concretos e abstratos. Um caso de uso concretoé iniciado por um agente e constitui um fluxo completo de eventos. "Completo" significa que uma instância do caso de uso executa a operação inteira chamada pelo agente.

Um caso de uso abstrato propriamente nunca é instanciado. Os casos de uso abstratos são incluídos em (consulte a Diretriz: Relacionamento de Inclusão), estendidos para (consulte a Diretriz: Relacionamento de Extensão) ou generalizados (consulte a Diretriz do Produto de Trabalho: Generalização do Caso de Uso) em outros casos de uso. Quando um caso de uso concreto é iniciado, uma instância do caso de uso é criada. Essa instância também exibe o comportamento especificado por seus casos de uso abstratos associados. Portanto, nenhuma instância separada é criada de casos de uso abstratos.

A distinção entre os dois é importante, porque são os casos de uso concretos que os agentes "verão" e iniciarão no sistema.

Você indica que um caso de uso é abstrato escrevendo seu nome em itálico.

Exemplo:

O caso de uso Criar Tarefa é incluído no caso de uso Registrar Ordem. Criar Tarefa é um caso de uso abstrato.

No Sistema para Administração de Depósito, o caso de uso abstrato, Criar Tarefa, é incluído no caso de uso Registrar Ordem. Quando o caso de uso Registrar Ordem é iniciado, uma instância de Registrar Ordem é criada e, independente de seguir o fluxo de eventos do Registro da Ordem, também segue o fluxo de eventos descrito no caso de uso incluído, Criar Tarefa. O caso de uso Criar Tarefa nunca é realizado por si mesmo, sempre como parte do Registrar Ordem (ou qualquer outro caso de uso em que esteja incluído). Criar Tarefa é, portanto, um caso de uso abstrato.

Estruturando o Modelo de Casos de Uso

Há três motivos principais para estruturar o modelo de casos de uso:

• Facilitar o entendimento dos casos de uso.
• Particionar o comportamento comum descrito em muitos casos de uso
• Facilitar a manutenção do modelo de casos de uso.

Entretanto, a estruturação não é a primeira coisa a fazer. Só faz sentido estruturar os casos de uso quando você souber um pouco mais sobre o comportamento deles, além de uma breve descrição em uma frase. Você deve pelo menos ter estabelecido um esquema passo a passo para o fluxo de eventos do caso de uso, a fim verificar se as suas decisões se basearam em um entendimento bem preciso do comportamento.

Para estruturar os casos de uso, há três tipos de relacionamentos. Você utilizará esses relacionamentos para fatorar partes de casos de uso que possam ser reutilizadas em outros casos de uso ou que sejam especializações ou opções para o caso de uso. O caso de uso que representa a modificação é chamado de caso de uso adicional. O caso de uso que é modificado é chamado de caso de uso base.

• Se houver uma parte de um caso de uso base que represente uma função da qual o caso de uso só depende do resultado, e não do método utilizado para produzir o resultado, você poderá fatorar essa parte em um caso de uso adicional. A adição é explicitamente inserida no caso de uso base, utilizando o relacionamento de inclusão. Consulte também a Diretriz: Relacionamento de Inclusão.
• Se houver uma parte de um caso de uso base que seja opcional ou desnecessária para entender a principal finalidade do caso de uso, você poderá fatorar essa parte em um caso de uso adicional para simplificar a estrutura do caso de uso base. A adição é implicitamente inserida no caso de uso base, utilizando o relacionamento de extensão. Consulte também a Diretriz: Relacionamento de Extensão.
• Se houver casos de uso com semelhantes no comportamento, na estrutura e na finalidade, as partes comuns podem ser fatoradas em um caso de uso base (pai) que é herdado por casos de uso adicionais (filhos). Os casos de uso filho podem inserir um novo comportamento e modificar o existente na estrutura herdada do caso de uso pai. Consulte também Diretriz do Produto de Trabalho: Generalização de Casos de Uso.

Você pode utilizar a generalização do agente para mostrar como os atores são especializações uns dos outros. Consulte também a Diretriz: Generalização de Agente.

Exemplo:

Considere parte do modelo de casos de uso de um Sistema de Gerenciamento de Ordens.

É útil separar o Cliente comum do Cliente de Internet, já que eles têm propriedades ligeiramente diferentes. Entretanto, como o Cliente de Internet exibe todas as propriedades de um Cliente, você pode dizer que esse Cliente de Internet é uma especialização do Cliente, indicado com uma generalização de agente.

Os casos de uso concretos neste diagrama são a Ordem por Telefone (iniciada pelo agente Cliente) e Ordem pela Internet (iniciada pelo Cliente de Internet). Esses casos de uso são variações do caso de uso mais geral Inserir Ordem, que neste exemplo é abstrato. O caso de uso Solicitar Catálogo representa um segmento opcional de comportamento que não é parte da principal finalidade de Inserir Ordem. Ele foi fatorado em um caso de uso abstrato para simplificar o caso de uso Inserir Ordem. O caso de uso Fornecer Dados do Cliente representa um segmento do comportamento que foi fatorado, desde que seja uma função separada da qual apenas o resultado esteja afetando o caso de uso Inserir Ordem. O caso de uso Fornecer Dados do Cliente também pode ser reutilizado em outros casos de uso. Tanto o caso de uso Solicitar Catálogo quanto o Fornecer Dados do Cliente são abstratos neste exemplo.

Este diagrama de casos de uso mostra parte do modelo de casos de uso de um Sistema de Gerenciamento de Ordens.

A tabela a seguir mostra uma comparação mais detalhada entre os três relacionamentos de casos de uso diferentes:

Outro aspecto da organização do modelo de casos de uso para facilitar o entendimento é agrupar os casos de uso em pacotes. O modelo de casos de uso pode ser organizado como uma hierarquia de pacotes de casos de uso, com "folhas" que são agentes ou casos de uso. Consulte também a Diretriz: Pacote de Caso de Uso.

Este gráfico mostra a hierarquia do modelo de casos de uso. As setas indicam a possível propriedade.

Os Casos de Uso São Sempre Relacionados a Agentes?

A execução de cada caso de uso inclui a comunicação com um ou mais atores. Uma instância de caso de uso é sempre iniciada por um agente solicitando algo do sistema. Isso implica que cada caso de uso deve ter associações de comunicações com os atores. O motivo dessa regra é forçar o sistema a fornecer apenas a funcionalidade de que os usuários precisam e nada mais. Ter casos de uso que ninguém solicita é uma indicação de que algo está errado no modelo de casos de uso ou nos requisitos.

Entretanto, há algumas exceções a essa regra:

• Se um caso de uso é abstrato (não instanciado separadamente), seu comportamento talvez não inclua a interação com qualquer agente. Nesse caso, não haverá associações de comunicação com os atores desse caso de uso abstrato.
• Um caso de uso filho em um relacionamento de generalização não precisa ter um agente associado a ele se o caso de uso pai descreve toda a comunicação do agente.
• Um caso de uso base em um relacionamento de inclusão não precisa ter um agente associado a ele se o caso de uso de inclusão descreve toda a comunicação do agente.
• Um caso de uso pode ser iniciado de acordo com um planejamento (por exemplo, uma vez por semana ou uma vez por dia), o que significa que o relógio do sistema é o iniciador. O relógio do sistema é interno ao sistema - e o caso de uso não é iniciado por um agente, mas por um evento de sistema interno. Se não ocorrer outra interação do agente no caso de uso, ele não terá nenhuma associação com os atores. Entretanto, para esclarecer, você pode utilizar um agente fictício "Tempo" para mostrar como o caso de uso é iniciado nos diagramas de casos de uso.

A Descrição do Relatório Sintético

A descrição do relatório sintético do modelo de casos de uso deve:

• Estabelecer quais são os principais casos de uso do sistema (o motivo pelo qual o sistema foi construído).
• Resumir os fatos técnicos importantes sobre o sistema.
• Indicar as delimitações do sistema - coisas que o sistema não deve executar.
• Resumir o ambiente do sistema como, por exemplo, plataformas-alvo e software existente.
• Descrever qualquer seqüência em que os casos de uso são executados normalmente no sistema.
• Especificar a funcionalidade não tratada pelo modelo de casos de uso.

Exemplo:

Segue, abaixo, uma amostra da descrição do relatório sintético do modelo de casos de uso da Máquina de Reciclagem:

Este modelo contém três atores e três casos de uso. O principal caso de uso é Reciclar Itens, que representa a principal finalidade da Máquina de Reciclagem.

Os casos de uso de suporte são:

• Imprimir Relatório Diário, que permite que um operador obtenha um relatório da quantidade de itens reciclados.

• Administrar o Item do Depósito, que permite que um operador altere o valor de reembolso de um tipo de item de depósito ou adicione novos tipos de item de depósito.